transactional

是的一般类上这么写@Transactional(readOnly=true) //配置事务 查询使用 只读public Demo{ //方法的写法 (增删改要写 ReadOnly=false 为可写) @Transactional (propagation=Propagation.REQUIRED,isolation=Isolation.DEFAULT,readOnly=false) public void saveUser(){ }}Propagation.REQUIRED ：有事务就处于当前事务中，没事务就创建一个事务isolation=Isolation.DEFAULT：事务数据库的默认隔离级别readOnly=false：可写 针对 增删改操作注意：方法的@Transactional会覆盖类上面声明的事务

Spring中的事务是以拦截器方式织入到业务代理对象中的，如果业务对象两个方法a，b都配置了事务属性，而在a方法实现中又调用b方法，则b方法声明的事务会在本次调用中不生效。解决的办法就是在a方法中不使用this.b()的方式调用方法b，而是从Spring容器中通过一种方式来获得业务代理对象，然后在代理对象上面调用它的b方法。这样b方法声明的事务就会有效啦。

service层在这层有逻辑判断`只有通过了逻辑判断才能允许事物的提交

org.springframework.transaction.annotation.Transactional

transactional systems交易系统

安装插件可以这么做，但不能体现这个IDE的好用之处 ，因为工具本身有一个可以管理插件的工具，并且所有插件都是可以在线安装的，非常方便。

spring 的aop是基于 jdk 动态代理和CGLIB代理实现的，如果把transactional 注解标注到protected、private，这将会被忽略，不会产生代理，虽然ide 不会报错，但是方法中的操作是不受控制的

Spring事务管理的方式大致可分为：编程式事务管理；声明式事务管理（又可以分为XML方式与注解方式）所以，如果要取消@transactional注解来实现事务管理，很简单，替换下面的配置即可：<tx:annotation-driven transaction-manager="transactionManager" mode="proxy" proxy-target-class="false" order="999"/><bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/><bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>

配置的事务就是在这个方法执行结束后提交，当然我这样说也不全面，应该说，事务在开启他的那个方法结束后就提交。你这个问题就是你数据库没有学好了，在一个事务空间（就是在一个事务里面）查询到的数据是这个事务空间里面的数据（换句话就是说你在这个事务里面添加的数据，在这个事务本身里面是能够看到的，只是其他事务不能看到这个数据而已）。希望我的回答对你有用。

Spring事务控制的注解方式你需要使用事务控制的时候用当然你要先理解什么是事务

用spring框架了吧。用来注解事务的。

当一个Spring Boot 项目在配置了多个数据源 , 在编写 Service层方法 的时候 , 直接在service方法的上添加的 @Transactional 直接实现事务管理的方式是失效的 . 以最近接触到的一个持久层框架使用的是Jpa的项目为例 , 该项目通过硬编码(配置类)的方式 , 在项目中配置了两个不同的数据源 , 所以这个项目分别根据两个数据源配置了各自的事务管理器 PlatformTransactionManager , 如下 : 第一个数据源的事务管理器配置类 : 第二个数据源事务管理器配置类 : 可以看到第二个事务管理器的Bean方法上添加了 @Primary 注解 , 所以在通过 PlatformTransactionManager 类型注入事务管理器的bean时 , 默认是根据类型去注入 , 如果该类型有多个 Bean , 如不通过bean的名字去注入 , 则默认是会注入被 @Primary 标识的bean的 ; 所以在这个项目中 , 当在业务层方法添加 @Transactional 注解时 , 默认是调用了 transactionManagerTwo 这个bean , 而我在编写service层的方法时 , 调用的是第一个数据源对应的Dao层方法 , 所以直接添加 @Transactional 是不能实现事务管理的 , 需要在使用 @Transactional 注解时指定使用的事务管理器的bean的名字 , 比如我这里调用的是第一个数据源的dao层方法 , 所以需要指定对应的事务管理器 : @Transactional(transactionManager = "transactionManagerOne") .

在开发过程中，经常会出现一个接口多表插入的情况，当其中一张表插入失败时就需要进行事务回滚了，SpringBoot为我们提供了@Transactional注解来进行事务回滚 1.需要将使用事务注解的方法设置为public； 2.如果没有在注解后做异常配置，只会对手动抛出的 throw new RuntimeException() 起作用； 3.若想对其余异常起作用，则需做类似配置 @Transactional(rollbackFor= Exception.class) ； 如果异常被抓起之后，需要回滚只能手动回滚，否则事务会认为异常已经被处理，就不在进行回滚 在使用注解后，在需要执行事务回滚的地方，很多时候往往抛出异常进行回滚后无法return或者做一些其余的逻辑，那么这种情况使用手动事务回滚是非常不错的。

transactionconfiguration是事务配置。transactional是事务的

就是对事务的控制吧，readonly=false 不是只读操作，可以读写操作吧

额，你发错分类了。。。transactional是JAVA的Spring框架的注解，倡导的是低入侵性，能够更良好的使用AOP面向切面编程。transactionlal加上了，代表这个类会被Spring操作或者声明，具体的操作根据transactional的内容而定。不加上当然Spring就不会自动识别了，需要IOC反向控制一下。transactional范围还是很广的，具体你需要查阅更多的资料才能学会它

在使用Spring的时候，进行事务管理变得相当简单：只要在方法上加上 @Transactional 就可以了，Spring就帮我们做了事务的开启、提交和回滚等操作，甚至我一度认为 @Transactional 就是等于Spring事务，只要是见到有数据库操作的方法，默认的统统加上此注解，自以为是的就万事大吉了。你是不是也有与我相同的经历呢：） 其实， @Transactional 也不是在任何的场景下都有效的，有时候会莫名的失效，在介绍之前呢，我们先来认识一下。 1、 @Transactional 注解可以用在哪些地方呢？ 作用于类： 表示所有public方法都配置相同的事务信息。 作用于方法： 代表方法的事务信息，其会覆盖类的事务哦！ 作用于接口： 这种方法极力不推荐，因为一旦使用cglib，注解会失效。 例如以下示例： 2、 @Transactional 注解还有哪些属性呢？ 接下来，我们一起看看 @Transactional 失效的场景。 1、作用在非public方法上会失效 原因是 在使用Spring AOP 代理时，会间接调用AbstractFallbackTransactionAttributeSource的方法computeTransactionAttribute获取事务信息，如果是非public就直接返回了，如下源码： 2、 propagation属性配置错误 TransactionDefinition.PROPAGATION_SUPPORTS：有没有事务无所谓 TransactionDefinition.PROPAGATION_NOT_SUPPORTED：非事务方式执行 TransactionDefinition.PROPAGATION_NEVER：有事务抛异常 3、 rollbackFor设置错误 Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。若需要在特定异常下回滚，则需要指定，比如第一个示例。 4、在同一个类中，方法调用 这个尤其被大家不熟悉，红色标出。 原因是什么，大家可以想一想，我们下一章来分析：） 5、异常被catch给吃掉了 6、数据库底层不支持事务，比如mysql的 myisam引擎。

在transactional replication, 经常会遇到数据同步延迟的情况。有时候这些延迟是由于在publication中执行了一个更新，例如update ta set col=? Where ?，这个更新包含巨大的数据量。在subscription端，这个更新会分解成多条命令（默认情况下每个数据行一个命令），应用到subscription上。 不得已的情况下，我们需要跳过这个大的事务，让replication继续运行下去。现在介绍一下transactional replication的一些原理和具体的方法当publication database的article发生更新时， 会产生相应的日志，Log reader会读取这些日志信息，将他们写入到Distribution 数据库的msrepl_transactions和msrepl_commands中。Msrepl_transactions中的每一条记录都有一个唯一标识xact_seqno，xact_seqno对应日志中的LSN。 所以可以通过xact_seqno推断出他们在publication database中的生成顺序，编号大的生成时间就晚，编号小的生成时间就早。Distributionagent包含两个子进程，reader和writer。 Reader负责从Distribution 数据库中读取数据，Writer负责将reader读取的数据写入到订阅数据库.reader是通过sp_MSget_repl_commands来读取Distribution数据库中（读取Msrepl_transactions表和Msrepl_Commands表）的数据下面是sp_MSget_repl_commands的参数定义CREATE PROCEDURE sys.sp_MSget_repl_commands ( @agent_id int, @last_xact_seqno varbinary(16), @get_count tinyint = 0, -- 0 = no count, 1 = cmd and tran (legacy), 2 = cmd only @compatibility_level int = 7000000, @subdb_version int = 0, @read_query_size int = -1 ) 这个存储过程有6个参数，在Transactional replication 中，只会使用前4个（并且第三个参数和第四个参数的值是固定不变的.分别为0和10000000）。下面是一个例子：execsp_MSget_repl_commands 46,0x0010630F000002A900EA00000000,0,10000000@agent_id表示Distributionagentid，每个订阅都会有一个单独的Distributionagent来处理数据。 带入@agent_id后，就可以找到订阅对应的publication 和所有的article。@last_xact_seqno 表示上一次传递到订阅的LSN。大致逻辑是：Reader读取subscription database的MSreplication_subscriptions表的transaction_timestamp列，获得更新的上一次LSN编号，然后读取分发数据库中LSN大于这个编号的数据。 Writer将读取到的数据写入订阅，并更新MSreplication_subscriptions表的transaction_timestamp列。然后Reader会继续用新的LSN来读取后续的数据，再传递给Writer，如此往复。如果我们手工更新transaction_timestamp列,将这个值设置为当前正在执行的大事务的LSN，那么distribution agent就会不读取这个大事务，而是将其跳过了。下面以一个实例演示一下环境如下Publisher: SQL108W2K8R21Distributor: SQL108W2K8R22Subscriber: SQL108W2K8R23图中高亮的publication中包含3个aritcles，ta,tb,tc其中ta包含18,218,200万数据，然后我们进行了一下操作在11：00进行了更新语句，update ta set c=-11后续陆续对表ta,tb,tc执行一些插入操作insert tb values(0,0)insert tc values(0,0)之后我们启动replication monitor ，发现有很大的延迟，distribution agent一直在传递a）操作产生的数据在subscription database中执行下面的语句,得到当前最新记录的事务编号declare @publisher sysname declare @publicationDB sysname declare @publication sysname set @publisher="SQL108W2K8R22" set @publicationDB="pubdb" set @publication="pubdbtest2"select transaction_timestamp From MSreplication_subscriptions where publisher=@publisher and publisher_db=@publicationDB and publication=@publication 在我的环境中，事务编号为0x0000014900004E9A0004000000000000返回到distribution database，执行下面的语句，得到紧跟在大事务后面的事务编号. 请将参数替换成您实际环境中的数据。（请注意，如果执行下列语句遇到性能问题，请将参数直接替换成值）declare @publisher sysname declare @publicationDB sysname declare @publication sysname declare @transaction_timestamp [varbinary](16) set @publisher="SQL108W2K8R21" set @publicationDB="publicationdb2" set @publication="pubtest" set @transaction_timestamp= 0x0000014900004E9A0004000000000000select top 1 xact_seqno from MSrepl_commands with (nolock) where xact_seqno>@transaction_timestamp and article_id in ( select article_id From MSarticles a inner join MSpublications p on a.publication_id=p.publication_id and a.publisher_id=p.publisher_id and a.publisher_db=p.publisher_db inner join sys.servers s on s.server_id=p.publisher_id where p.publication=@publication and p.publisher_db=@publicationDB and s.name=@publisher ) and publisher_database_id =( select id From MSpublisher_databases pd inner join MSpublications p on pd.publisher_id=p.publisher_id inner join sys.servers s on pd.publisher_id=s.server_id and pd.publisher_db=p.publisher_db where s.name=@publisher and p.publication=@publication and pd.publisher_db=@publicationDB ) Order by xact_seqno在我的环境中，事务编号为0x0000018C000001000171在subscription database中执行下面的语句，跳过大的事务。请将参数替换成您实际环境中的数据declare @publisher sysnamedeclare @publicationDB sysname declare @publication sysname declare @transaction_timestamp [varbinary](16) set @publisher="SQL108W2K8R22" set @publicationDB="pubdb" set @publication="pubdbtest2" set @transaction_timestamp= 0x0000018C000001000171update MSreplication_subscriptions set transaction_timestamp=@transaction_timestamp where publisher=@publisher and publisher_db=@publicationDB and publication=@publication 执行完成后开启distribution agent job即可。接下来您就会发现，事务已经成功跳过，ta在订阅端不会被更新，后续的更新会逐步传递到订阅，延迟消失。您可能感兴趣的文章:MSSQL事务的存储过程MSSQL 事务说明c#实现sqlserver事务处理示例使用Sqlserver事务发布实现数据同步(sql2008)SQLServer分布式事务问题Sqlserver 存储过程中结合事务的代码

交易型领导(Transactional Leadership)是贺兰德(Hollander)於1978年所提出。Hollander认为领导行为乃发生在特定情境之下时，领导者和被领导者相互满足的交易过程，即领导者藉由明确的任务及角色的需求来引导与激励部属完成组织目标。

Transactional Leadership 交易型领导者例如1. A contingent analysis of transformational and transactional leadership变革型领导与交易型领导的权变分析2. The different size elementary schools had different perception of principals " transactional leadership . 不同学校规模校长交易领导有显着差异。 参考http://www.ichacha.net/transactional%20leadership.html

不可能不会起作用的，你是不是在service层用try catch捕捉异常了？或者你数据库用的是mysql，引擎用的是myisam？

要用spring.jar里面的，因为这个注解是事务管理用的。public class MultiTxService { @Transactional("tran_1") public void addTest(int id){ } @Transactional("tran_2") public void deleteTest(int id){ }}

这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。 根据 MySQL 的官方文档： https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html 从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是无济于事。 如下代码所示，当前数据源若没有配置事务管理器，那也是白搭！ @Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } 如果此时把 @Service 注解注释掉，这个类就不会被加载成一个 Bean，那这个类就不会被 Spring 管理了，事务自然就失效了。 以下引自spring官方文档： 大致意思是： @Transactional 只能用于 public 的方法上，否则事务会失效。如果要用在非 public 方法上，可以开启 AspectJ 代理模式。 例1： 例1 中，update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？ 例2： 例2 中，update方法上面加了 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？ 很遗憾，这两个例子中， updateOrder 方法上的事务都不管用 因为它们发生了自身调用，就是调该类自己的方法，而没有经过 Spring 的代理类，默认只有在外部调用事务才会生效，这也是老生常谈的经典问题了。 6.1这个也是出现比较多的场景：把异常吃了，然后又不抛出来，事务也不会回滚！ 6.2 这样事务也是不生效的，因为默认回滚的是：RuntimeException，如果你想触发其他异常的回滚，需要在注解上配置一下，如： @Transactional(rollbackFor = Exception.class) 这个配置仅限于 Throwable 异常类及其子类。 Propagation.NOT_SUPPORTED：表示不以事务运行，当前若存在事务则挂起。这表示不支持以事务的方式运行，所以即使事务生效也是白搭！

用过spring的人应该都使用过@Transactional注解了在只有一个TransactionManager时没有问题配置如下：Java代码 <!-- 事务配置 --> <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory" /> </bean> <!-- 使用annotation定义事务 --> <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="false"/> 如果有两个事务管理器 如 HibernateTransactionManager和 DataSourceTransactionManager就不好办了 为什么不直接在@Transactional上指定事务管理器呢 比如说这样Java代码 @Transactional(transactionManager=DataSourceTransactionManager)