数据库事务管理

最新推荐文章于 2024-08-23 17:37:15 发布

刘老师博客

最新推荐文章于 2024-08-23 17:37:15 发布

阅读量222

点赞数

分类专栏：数据库事务管理文章标签：数据库事务

本文链接：https://blog.csdn.net/qq_39526562/article/details/77546706

版权

数据库事务管理专栏收录该内容

0 篇文章 0 订阅

订阅专栏

不管你直接采用JDBC进行数据库事务操作，还是使用基于Spring或EJB的声明式事务功能进行事务管理，它们最终都是使用底层数据库的事务管理功能完成最终任务的。

数据库事务有严格的定义，它必须同时满足四个特性：原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabiliy），简称为ACID。下面是对每个特性的说明：

 原子性：表示组成一个事务的多个数据库操作是一个不可分隔的原子单元，只有所有的操作执行成功，整个事务才提交，事务中任何一个数据库操作失败，已经执行的任何操作都必须撤销，让数据库返回到初始状态；

 一致性：事务操作成功后，数据库所处的状态和它的业务规则是一致的，即数据不会被破坏。如从A账户转账100元到B账户，不管操作成功与否，A和B的存款总额是不变的；

 隔离性：在并发数据操作时，不同的事务拥有各自数据空间，它们的操作不会对对方产生干扰。准确的说，并非要求做到完全无干扰，数据库规定了多种事务隔离级别，不同隔离级别对应不同的干扰程度，隔离级别越高，数据一致性越好，但并发性越弱；

 持久性：一旦事务提交成功后，事务中所有的数据操作都必须被持久化到数据库中，即使提交事务后，数据库马上崩溃，在数据库重启时，也必须能保证能够通过某种机制恢复数据。

数据库并发问题

一个数据库可能拥有多个访问客户端，这些客户端都可以并发方式访问数据库。数据库中的相同数据可能同时被多个事务访问，如果没有采取必要的隔离措施，就会导致各种并发问题，破坏数据的完整性。这些问题可以归结为5类，包括3类数据读问题（脏读、幻象读和不可重复读）以及2类数据更新问题（第一类丢失更新和第二类丢失更新）。下面，我们分别通过实例讲解引发问题的场景。

脏读（dirty read）

在讲解脏读前，我们先讲一个笑话：一个有结巴的人在饮料店柜台前转悠，老板很热情地迎上来：“喝一瓶？”，结巴连忙说：“我…喝…喝…”，老板麻利地打开易拉罐递给结巴，结巴终于憋出了他的那句话：“我…喝…喝…喝不起啊！”。在这个笑话中，饮料店老板就对结巴进行了脏读。

A事务读取B事务尚未提交的更改数据，并在这个数据的基础上操作。如果恰巧B事务回滚，那么A事务读到的数据根本是不被承认的。来看取款事务和转账事务并发时引发的脏读场景：

在这个场景中，B希望取款500元而后又撤销了动作，而A往相同的账户中转账100元，就因为A事务读取了B事务尚未提交的数据，因而造成账户白白丢失了500元。在Oracle数据库中，不会发生脏读的情况。

不可重复读（unrepeatable read）

不可重复读是指A事务读取了B事务已经提交的更改数据。假设A在取款事务的过程中，B往该账户转账100元，A两次读取账户的余额发生不一致：

在同一事务中，T4时间点和T7时间点读取账户存款余额不一样。

幻象读（phantom read）

A事务读取B事务提交的新增数据，这时A事务将出现幻象读的问题。幻象读一般发生在计算统计数据的事务中，举一个例子，假设银行系统在同一个事务中，两次统计存款账户的总金额，在两次统计过程中，刚好新增了一个存款账户，并存入100元，这时，两次统计的总金额将不一致：

如果新增数据刚好满足事务的查询条件，这个新数据就进入了事务的视野，因而产生了两个统计不一致的情况。

幻象读和不可重复读是两个容易混淆的概念，前者是指读到了其它已经提交事务的新增数据，而后者是指读到了已经提交事务的更改数据（更改或删除），为了避免这两种情况，采取的对策是不同的，防止读取到更改数据，只需要对操作的数据添加行级锁，阻止操作中的数据发生变化，而防止读取到新增数据，则往往需要添加表级锁——将整个表锁定，防止新增数据（Oracle使用多版本数据的方式实现）。

第一类丢失更新

A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来：

A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。

第二类丢失更新

A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：

上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。

数据库锁机制

数据并发会引发很多问题，在一些场合下有些问题是允许的，但在另外一些场合下可能却是致命的。数据库通过锁的机制解决并发访问的问题，虽然不同的数据库在实现细节上存在差别，但原理基本上是一样的。

按锁定的对象的不同，一般可以分为表锁定和行锁定，前者对整个表进行锁定，而后者对表中特定行进行锁定。从并发事务锁定的关系上看，可以分为共享锁定和独占锁定。共享锁定会防止独占锁定，但允许其它的共享锁定。而独占锁定既防止其它的独占锁定，也防止其它的共享锁定。为了更改数据，数据库必须在进行更改的行上施加行独占锁定，INSERT、UPDATE、DELETE和SELECT FOR UPDATE语句都会隐式采用必要的行锁定。下面我们介绍一下ORACLE数据库常用的5种锁定：

 行共享锁定：一般通过SELECT FOR UPDATE语句隐式获得行共享锁定，在Oracle中你也可以通过LOCK TABLE IN ROW SHARE MODE语句显式获得行共享锁定。行共享锁定并不防止对数据行进行更改的操作，但是可以防止其它会话获取独占性数据表锁定。允许进行多个并发的行共享和行独占性锁定，还允许进行数据表的共享或者采用共享行独占锁定；

 行独占锁定：通过一条INSERT、UPDATE或DELETE语句隐式获取，或者通过一条LOCK TABLE IN ROW EXCLUSIVE MODE语句显式获取。这个锁定可以防止其它会话获取一个共享锁定、共享行独占锁定或独占锁定；

 表共享锁定：通过LOCK TABLE IN SHARE MODE语句显式获得。这种锁定可以防止其它会话获取行独占锁定（INSERT、UPDATE或DELETE），或者防止其它表共享行独占锁定或表独占锁定，它允许在表中拥有多个行共享和表共享锁定。该锁定可以让会话具有对表事务级一致性访问，因为其它会话在你提交或者回溯该事务并释放对该表的锁定之前不能更改这个被锁定的表；

 表共享行独占：通过LOCK TABLE IN SHARE ROW EXCLUSIVE MODE语句显式获得。这种锁定可以防止其它会话获取一个表共享、行独占或者表独占锁定，它允许其它行共享锁定。这种锁定类似于表共享锁定，只是一次只能对一个表放置一个表共享行独占锁定。如果A会话拥有该锁定，则B会话可以执行SELECT FOR UPDATE操作，但如果B会话试图更新选择的行，则需要等待；

 表独占：通过LOCK TABLE IN EXCLUSIVE MODE显式获得。这个锁定防止其它会话对该表的任何其它锁定。

事务隔离级别

尽管数据库为用户提供了锁的DML操作方式，但直接使用锁管理是非常麻烦的，因此数据库为用户提供了自动锁机制。只要用户指定会话的事务隔离级别，数据库就会分析事务中的SQL语句，然后自动为事务操作的数据资源添加上适合的锁。此外数据库还会维护这些锁，当一个资源上的锁数目太多时，自动进行锁升级以提高系统的运行性能，而这一过程对用户来说完全是透明的。

ANSI/ISO SQL 92标准定义了4个等级的事务隔离级别，在相同数据环境下，使用相同的输入，执行相同的工作，根据不同的隔离级别，可以导致不同的结果。不同事务隔离级别能够解决的数据并发问题的能力是不同的。

表 1 事务隔离级别对并发问题的解决情况

事务的隔离级别和数据库并发性是对立的，两者此增彼长。一般来说，使用READUNCOMMITED隔离级别的数据库拥有最高的并发性和吞吐量，而使用SERIALIZABLE隔离级别的数据库并发性最低。

SQL 92定义READ UNCOMMITED主要是为了提供非阻塞读的能力，Oracle虽然也支持READ UNCOMMITED，但它不支持脏读，因为Oracle使用多版本机制彻底解决了在非阻塞读时读到脏数据的问题并保证读的一致性，所以，Oracle的 READ COMMITTED隔离级别就已经满足了SQL 92标准的REPEATABLE READ隔离级别。

SQL 92推荐使用REPEATABLE READ以保证数据的读一致性，不过用户可以根据应用的需要选择适合的隔离等级。

Ø Serializable ：串行化；（隔离级别最高） 1

Ø Repeatable Read ：可重复读； 2

Ø Read Commited ：读已提交数据； 4

Ø Read Uncommited ：读未提交数据；（隔离级别最低） 8

Hiberate 中的隔离级别的设置

在 Hibernate 的配置文件中hibernate.connection.isolation=2

数据库事务总结

一、数据库事务概念

数据库事务的特征： ACID

Atomic （原子性）、Consistency （一致性）、 Isolation （隔离性）和 Durability （持久性）。 DBMS 用日志来保证数据的原子性、一致性和持久性；用锁的机制来保证数据的隔离性。

二、事务的边界

数据库支持 2 种事务模式：自动提交和手动提交。

JDBC API 的事务边界

try

{

Connection conn = java.sql.DriverManager,.getConnection(dbUrl,dbUser,dbPwd);

conn.setAutoCommit( false ); // 设置成手动模式

stmt = conn.createStatement();

stmt.executeUpdate( " ." ); // 数据库更新1

stmt.executeUpdate( " ." ); // 数据库更新2

conn.commit();

}

catch (Exception e)

{

conn.rollback();

}

finally

{

stmt.close();

conn.close();

}

hibernate API 声明事务边界

Session session = factory.openSession();

Transaction tx;

try

{

tx = session.beginTransaction(); // 开始事务

// 执行操作

。。。。。

tx.commit();

}

catch (Exception e)

{

if (tx != null )

{

tx.rollback();

}

finally

{

session.close();

}

注：一个 session 可以对应多个事务，但是推荐的做法是一个 session 对应一个事务。

三、多事务的并发问题

当多个事务同时访问相同的数据的时候，程序如果没有采取适当的隔离措施，就会发生数据库的并发问题。常见的并发问题有：

第一类丢失更新：撤消事务的时候，把其他的事务已经提交的数据给覆盖了；

脏读；读了没有提交的数据；

幻象读：一个事务读到另外一个事务已经提交的新插入的数据；

不可重复读：一个事务读到另外一个事务已经提交的更新的数据；

第二类丢失更新：一个事务覆盖另外一个事务已经提交的更新数据。

四、锁

一般地，大型的 DBMS 都会自动的管理锁定机制，但是在对数据的安全性、完整性和一致性有特殊要求的地方，可以由事务本身来管理琐的机制。

有一点要关注的是：锁的粒度越大，隔离性越好，并发性越差。

按照锁的程度来分有：

共享锁：用读操作，非独占的，其他事务可以读，但是不能更新，并发性好；

独占锁：用与 insert update 和 delete 等语句，其他事务不能读，也不能改，并发性差；

更新锁：执行 update 的时候，加锁。

死琐：多是事务分别锁定了一个资源，又请求锁定对方已经锁定的资源，就造成了请求环。

降低死锁的最好办法是使用短事务。

五、数据库的事务隔离级别

数据库提供 4 种事务隔离级别：

Serializable ：串行化；（隔离级别最高） 1

Repeatable Read ：可重复读； 2

Read Commited ：读已提交数据； 4

Read Uncommited ：读未提交数据；（隔离级别最低） 8

Hiberate 中的隔离级别的设置

在 Hibernate 的配置文件中hibernate.connection.isolation=2

六、悲观锁和乐观琐

从应用程序的角度来看，锁分为悲观锁和乐观锁。

悲观锁：显示的为程序加锁，但是降低并发性。

Select ……. For update;

在 Hibernate 中的代码

Session.get(Account.class,netLong(1),LockMode.UPGRADE) ； // 程序采用悲观锁

乐观锁：依靠 DBMS 来管理锁，程序依靠版本控制来避免并发问题。

在对象 - 关系映射的文件中，用<version> 或者 <timestamp> 可以管理并发。乐观琐比悲观琐有更好的并发性，优先考虑乐观琐。

Spring事务处理

spring支持编程式事务管理和声明式事务管理两种方式。

编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。

声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。

显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。

声明式事务管理也有两种常用的方式，一种是基于tx和aop名字空间的xml配置文件，另一种就是基于@Transactional注解。显然基于注解的方式更简单易用，更清爽。

spring事务特性

spring所有的事务管理策略类都继承自org.springframework.transaction.PlatformTransactionManager接口

其中TransactionDefinition接口定义以下特性：

事务隔离级别

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量：

Ø TransactionDefinition.ISOLATION_DEFAULT：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。

Ø TransactionDefinition.ISOLATION_READ_UNCOMMITTED：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读，不可重复读和幻读，因此很少使用该隔离级别。比如PostgreSQL实际上并没有此级别。

Ø TransactionDefinition.ISOLATION_READ_COMMITTED：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。

Ø TransactionDefinition.ISOLATION_REPEATABLE_READ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。该级别可以防止脏读和不可重复读。

Ø TransactionDefinition.ISOLATION_SERIALIZABLE：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

事务传播行为

所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

Ø TransactionDefinition.PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是默认值。

Ø TransactionDefinition.PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。

Ø TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

Ø TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。

Ø TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

Ø TransactionDefinition.PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

Ø TransactionDefinition.PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

事务超时

所谓事务超时，就是指一个事务所允许执行的最长时间，如果超过该时间限制但事务还没有完成，则自动回滚事务。在TransactionDefinition 中以 int 的值来表示超时时间，其单位是秒。

默认设置为底层事务系统的超时值，如果底层数据库事务系统没有设置超时值，那么就是none，没有超时限制。

事务只读属性

只读事务用于客户代码只读但不修改数据的情形，只读事务用于特定情景下的优化，比如使用Hibernate的时候。

默认为读写事务。

“只读事务”并不是一个强制选项，它只是一个“暗示”，提示数据库驱动程序和数据库系统，这个事务并不包含更改数据的操作，那么JDBC驱动程序和数据库就有可能根据这种情况对该事务进行一些特定的优化，比方说不安排相应的数据库锁，以减轻事务对数据库的压力，毕竟事务也是要消耗数据库的资源的。

但是你非要在“只读事务”里面修改数据，也并非不可以，只不过对于数据一致性的保护不像“读写事务”那样保险而已。

因此，“只读事务”仅仅是一个性能优化的推荐配置而已，并非强制你要这样做不可

spring事务回滚规则

指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。

默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚。可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。还可以编程性的通过setRollbackOnly()方法来指示一个事务必须回滚，在调用完setRollbackOnly()后你所能执行的唯一操作就是回滚。

myBatis为例基于注解的声明式事务管理配置@Transactional

spring.xml

1.

2. <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">

3. <property name="dataSource" ref="dataSource" />

4. <property name="configLocation">

5. <value>classpath:mybatis-config.xml</value>

6. </property>

7. </bean>

9.

10. <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">

11. <property name="basePackage">

12. <value>

13. com.baobao.persistence.test

14. </value>

15. </property>

16. <property name="sqlSessionFactory" ref="sqlSessionFactory" />

17. </bean>

18.

19.

20. <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

21. <property name="dataSource" ref="dataSource" />

22. </bean>

23.

24.

25. <tx:annotation-driven transaction-manager="transactionManager"/></span></span>

添加tx名字空间

1. xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"

3. xsi:schemaLocation="http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd

4. http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd"

MyBatis自动参与到spring事务管理中，无需额外配置，只要org.mybatis.spring.SqlSessionFactoryBean引用的数据源与DataSourceTransactionManager引用的数据源一致即可，否则事务管理会不起作用。

@Transactional注解

@Transactional属性

用法

@Transactional 可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有 public 方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。

虽然 @Transactional 注解可以作用于接口、接口方法、类以及类方法上，但是 Spring 建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。另外， @Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常。

默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。

1. @Autowired

2. private MyBatisDao dao;

4. @Transactional

5. @Override

6. public void insert(Test test) {

7. dao.insert(test);

8. throw new RuntimeException("test");//抛出unchecked异常，触发事物，回滚

9. }

noRollbackFor

1. @Transactional(noRollbackFor=RuntimeException.class)

2. @Override

3. public void insert(Test test) {

4. dao.insert(test);

5. //抛出unchecked异常，触发事物，noRollbackFor=RuntimeException.class,不回滚

6. throw new RuntimeException("test");

7. }

类，当作用于类上时，该类的所有 public 方法将都具有该类型的事务属性

1. @Transactional

2. public class MyBatisServiceImpl implements MyBatisService {

4. @Autowired

5. private MyBatisDao dao;

8. @Override

9. public void insert(Test test) {

10. dao.insert(test);

11. //抛出unchecked异常，触发事物，回滚

12. throw new RuntimeException("test");

13. }

propagation=Propagation.NOT_SUPPORTED

1. @Transactional(propagation=Propagation.NOT_SUPPORTED)

2. @Override

3. public void insert(Test test) {

4. //事物传播行为是PROPAGATION_NOT_SUPPORTED，以非事务方式运行，不会存入数据库

5. dao.insert(test);

6. }

myBatis为例基于注解的声明式事务管理配置.xml配置

主要为aop切面配置，只看xml就可以了

1.

2. <tx:advice id="advice" transaction-manager="transactionManager">

3. <tx:attributes>

4. <tx:method name="update*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception"/>

5. <tx:method name="insert" propagation="REQUIRED" read-only="false"/>

6. </tx:attributes>

7. </tx:advice>

9. <aop:config>

10. <aop:pointcut id="testService" expression="execution (* com.baobao.service.MyBatisService.*(..))"/>

11. <aop:advisor advice-ref="advice" pointcut-ref="testService"/>

</aop:config>

刘老师博客

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
数据库事务管理

不管你直接采用JDBC进行数据库事务操作，还是使用基于Spring或EJB的声明式事务功能进行事务管理，它们最终都是使用底层数据库的事务管理功能完成最终任务的。数据库事务有严格的定义，它必须同时满足四个特性：原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabiliy），简称为ACID。下面是对每个特性的说明： 原子性：表示组成一
复制链接

扫一扫

专栏目录