皮皮网

【开源书源码】【ruby 源码剖析】【spi协议源码】service注解源码_@service注解原理

2024-12-26 00:55:35 来源:融媒体app源码

1.Spring Boot中Service用@Transactional 注解在方法上,注注解只在最外层方法起作用吗?
2.Spring boot @Service 和@Configuration 的解源区别?
3.@service注解(java@service注解)
4.dubbo注解是什么意思?

service注解源码_@service注解原理

Spring Boot中Service用@Transactional 注解在方法上,只在最外层方法起作用吗?

       一般来说function2和function1用的原理是同一个Transaction。

       这个取决于@Transactional 的注注解 propagation设置(事务的传播性)

       默认的是

@Transactional(propagation=propagation.REQUIRED)

       也就是使用同一个Transaction。也可以按需求设置成 NESTED 或者 REQUIRES_NEW。解源

//in A.java

       Class A {

           @Transactional(propagation=propagation.REQUIRED)

           public void aMethod {

               B b = new B();

               b.bMethod();

           }

       }

        

       //in B.java

       Class B {

           @Transactional(propagation=propagation.REQUIRED)

           public void bMethod {  //something }

       }在上面这个例子中,原理开源书源码传播性被设为了REQUIRED,注注解注意,解源这是原理默认值,也即不进行该参数配置等于配置成REQUIRED。注注解

          REQUIRED的解源含义是,支持当前已经存在的原理事务,如果还没有事务,注注解就创建一个新事务。解源在上面这个例子中,原理假设调用aMethod前不存在任何事

       务,那么执行aMethod时会自动开启一个事务,而由aMethod调用bMethod时,由于事务已经存在,因此会使用已经存在的事务(也就是执行

       aMethod之前创建的那个事务)。

          对于这样的ruby 源码剖析配置,如果bMethod过程中发生异常需要回滚,那么aMethod中所进行的所有数据库操作也将同时被回滚,因为这两个方法使用了同一个事务。

          MANDATORY的含义是,支持当前已经存在的事务,如果还没有事务,就抛出一个异常。如果上例中aMethod的传播性配置为

       MANDATORY,我们就无法在没有事务的情况下调用aMethod,因此,传播性为MANDATORY的方法必定是一个其他事务的子事务,当逻辑上独

       立存在没有意义或者可能违反数据、事务完整性的时候,就可以考虑设置这样的传播性设置。

          NESTED的含义是,在当前事务中创建一个嵌套事务,如果还没有事务,那么就简单地创建一个新事务。

          REQUIRES_NEW的含义是,挂起当前事务,spi协议源码创建一个新事务,如果还没有事务,就简单地创建一个新事务。

          请注意以上两者的区别,大多数情况下一上两种传播性行为是类似的,不过在事务回滚的问题上,以上两者有很大的区别。

          首先,REQUIRES_NEW会创建一个与原事务无关的新事务,尽管是由一个事务调用了另一个事务,但却没有父子关系。

          如果bMethod的传播性是REQUIRES_NEW,而抛出了一个异常,则bMethod一定会被回滚,而如果aMethod捕获并处理了这个

       bMethod抛出的异常,那么aMethod仍有可能成功提交。当然,如果aMethod没有处理这个异常,那么aMethod也会被回滚。

          如果aMethod在bMethod完成后出现了异常,linuxcnc源码结构那么bMethod已经提交而无法回滚,只有aMethod被回滚了。

          而对于NESTED,虽然也会创建一个新事务,但是这个事务与调用者是有父子关系的相互依存的。

          如果bMethod的传播性是NESTED,而抛出了一个异常,事务的回滚行为与REQUIRES_NEW是一致的。

          但是如果aMethod在bMethod完成后出现了异常,bMethod同样也会被回滚。因为事实上,EJB中没有对于NESTED传播性的类似实现,NESTED并不是真正启动了一个事务,而是开启了一个新的savepoint。

          NEVER的含义很简单,就是强制要求不在事务中运行,如果当前存在一个事务,则抛出异常,因此如果bMethod传播性是NEVER,则一定抛出异常。柳州麻将源码

          NOT_SUPPORTED的含义是,强制不在事务中运行,如果当前存在一个事务,则挂起该事务。

          SUPPORTS的含义是,支持当前事务,如果没有事务那么就不在事务中运行。SUPPORTS传播性的逻辑含义比较模糊,因此一般是不推荐使用的。

Spring boot @Service 和@Configuration 的区别?

       注解不是这么看的,注解的定义只是说它能作用在哪儿,它能提供哪些参数,具体什么时候用到,那是spring里的东西。注解我的理解只是一个标签,告诉java这个类是个什么东西,比如业务引用了某个类,通过getAnnotation()方法来知道:“哦,原来我引用的类是这个东西啊”,这样就可以对业务引用的这个类进行一些特殊处理了。

       不然照你这么说那jdk提供的这些注解,比如:

       难道也是重复没有作用的吗?

       @Service是告诉spring,这个类是一个服务,个人觉得是随着SOA理念的发展而逐步传播开的。将业务分为一个个的服务,实现服务的重用,也进一步降低耦合度。

       另外还有一个非常常见的注解@Component,它的意思就是一个组件,相对来说比较中立,仅仅作为某种功能放在那里。老实说,其实@Service和@Component才是基本没什么差别,两者相互代替也没什么毛病。

       所以我个人还觉得啊,注解还有一个作用就是将功能模块分类,服务相关的类统一加上注解@Service,放到一个文件夹下。所有组件@Component也是放到一起,另外那些@Mapper啊,@Controller啊,让整个项目层次清晰,结构完善。

       @Configuration告诉spring,这个类是一个配置类,和写xml进行配置差不多,只是有些人不喜欢写xml进行配置,那就直接写类加上@Configuration来配置咯

       最后再补充网上说的一句话,也就是我前面提到的spring做的一些特殊处理了:“这几个注解几乎可以说是一样的:因为被这些注解修饰的类就会被Spring扫描到并注入到Spring的bean容器中。”

@service注解(java@service注解)

       @Service注解无法被扫描到的问题

       偶然发现在Service层创建接口和实现类,且在实现类中加入@Service注解,但并不能通过

       SpringService层配置文件中配置的扫描配置

       context:component-scanbase-package="com.*.Service"/context:component-scan

       成功扫描并加入IOC容器中

       打开Service层包中,发现接口名采用了IUserService.java的写法

       将接口名改为IuserService.java后

       @Service注解能够被正常扫描

       结论:不建议在使用注解的接口或实现类中使用连续大写字母的名称,Spring在扫描注解时会自动将头字母改为小写并加入到IOC容器中,连续的大写字母会导致注解无法被扫描到

@Service注解是标注在实现类上的的接口中添加注解还是在实现类impl

       @Service注解是标注在实现类上的

       因为@Service是把spring容器中的bean进行实例化,也就是等同于new操作,只有实现类是可以进行new实例化的,而接口则不能,所以是加在实现类上的。

       IOC的思想:A不直接调用B,而是通过调用生产B的工厂(工厂模式),由B工厂来创建B

       有三种普通注入方式,分为构造函数的注入、属性注入、接口注入。

       将注入方式交给第三方,通过bean的注解,想调用时直接通过注解注入。

       所以通过注解注入bean,就是实例化依赖类的方式,

       这也是为什么要将@Service和@Repository放到实现类上面而不是接口类上面,

       接口只是一个规范,需要各种实现类去实现这个接口,我们要用的就是这些实用类的方法。

       如果采用@Autowired来注解,则同样无需指定name属性,若是实现该接口有多个类,则需要通过@Qualifier来做区分

       @Service、@Repository注解是放到service或者dao类的实现类还是接口类中

       -----------------------------------

       在service的接口中添加注解还是在实现类impl

@Service注解的使用

       @Service注解的使用

       首先,在applicationContext.xml文件中加一行:

       context:component-scanbase-package="com.hzhi.clas"/

       加上这一行以后,将自动扫描路径下面的包,如果一个类带了@Service注解,将自动注册到Spring容器,不需要再在applicationContext.xml文件定义bean了,类似的还包括@Component、@Repository、@Controller。

       比如下面这个类:

       @Service("courseDAO")

       @Scope("prototype")

       publicclassCourseDAOImplextendsHibernateDaoSupportimplementsCourseDAO{ ......}

       其作用就相当于applicationContext.xml文件里面的:

       beanid="courseDAO"class="com.hzhi.course.dao.CourseDAOImpl"scope="prototype"/bean

dubbo注解是什么意思?

       Dubbo是阿里巴巴开发的一个高性能Java RPC框架,提供了很多注解来简化服务的发布和引用。其中最重要的两个注解是@Service和@Reference。@Service注解用于在服务提供端标记服务接口实现类,让Dubbo框架能够正确发布此服务。@Reference注解用于在服务消费端标记服务接口变量,让Dubbo框架能够自动注入此服务。

       @Service注解是Dubbo框架中用于标记服务暴露的注解。使用@Service注解标记的类会被Dubbo框架扫描并注入到本地服务暴露器中,从而能够被外部服务消费者调用。在使用@Service注解的同时,还可以配置一些服务发布相关的属性,例如版本号、超时时间等等。

       @Reference注解是Dubbo框架中用于标记服务引用的注解。使用@Reference注解标记的类或接口变量会被Dubbo框架自动注入相关的服务实现类,从而可以直接调用远程服务。在使用@Reference注解的同时,还可以配置一些服务引用相关的属性,例如版本号、超时时间等等。这让服务消费者在使用Dubbo框架时更加方便快捷。