`
zy77612
  • 浏览: 278497 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

spring 事务

阅读更多

 

 

事务传播属性

Propagation (传播)

执行方法前已存在事务 执行方法时没有事务
REQUIRED 加入到事务中 创建新的事务
NOT_SUPPORTED 挂起存在事务,执行完方法后恢复挂起的事务 不开启事务,正常执行
REQUIRESNEW 持起存在事,创建新的事务,结束方法后,恢复挂起的事务 创建新的事务
MANDATORY 加入到事务中 抛出异常
SUPPORTS 加入到事务中 不开启事务,正常执行
NEVER 抛出异常 不开启事务,正常执行
NESTED 加入到事务,运行在嵌套的事务中(嵌套事务的回滚不会对外部事务造成影响,外部事务的回滚影响嵌套的事务) 则按REQUIRED属性执行.它使用了一个单独的事务

 

 

 

数据库事务隔离级别
Read Uncommited 读未提交数据(会出现脏读,不可重复读和幻读) 
Read Commited 读已提交数据(会出现不可重复读和幻读) 
Repeatable Read 可重复读(会出现幻读) 
Serializable 串行化 

 

 

 

 

 

 

 

 

 

  •  脏读:一个事务读取到另一事务未提交的更新新据。
      举个例子:预订房间。
     有一张Reservation表,往表中插入一条记录,来订购一个房间。
     事务1:在Reservation表中插入一条记录,用于预订99号房间。
     事务2:查询,尚未预定的房间列表,因为99号房间,已经被事务1预订。所以不在列表中。
     事务1:信用卡付款。由于付款失败,导致整个事务回滚。
      所以插入到Reservation 表中的记录并不置为持久(即它将被删除)
     现在99号房间则为可用。
     所以,事务2所用的是一个无效的房间列表,因为99号房间,已经可用。如果它是最后一个没有被预定的房间,那么这将是一个严重的失误。
     注:脏读的后果很严重
  • 不可重复读:在同一事务中,多次读取同一数据返回的结果有所不同。换句话说就是,后续读取可以读到另一事务已提交的更新数据。相反,“可重复读”在同一事务中多次读取数据时,能够保证所读数据一样,也就是,后续读取不能读到另一事务已提交的更新数据。
     举个例子:
     事务1:查询有双人床房间。99号房间,有双人床。
     事务2:将99号房间,改成单人床房间。
     事务1:再次执行查询,请求所有双人床房间列表,99号房间不再列表中了。也就是说,
            事务1,可以看到其他事务所做的修改。
  • 幻读:一个事务读取到另一事务已提交的insert数据。
     举个例子:
     事务1:请求没有预定的,双人床房间列表。
     事务2:向Reservation表中插入一个新纪录,以预订99号房间,并提交。
     事务1:再次请求有双人床的未预定的房间列表,99号房间,不再位于列表中。
     也如:Transaction 1 读取满足某种搜索条件的一些行,然后 Transaction 2 插入了符合 Transaction 1 的搜索条件的一个新行。如果 Transaction 1 重新执行产生原来那些行的查询,就会得到不同的行。
     注:幻读,针对的是,Insert操作。如果事务2,插入的记录,没有提交。那么同时也是脏读。

x锁 排他锁 被加锁的对象只能被持有锁的事务读取和修改,其他事务无法在该对象上加其他锁,也不能读取和修改该对象
s锁 共享锁 被加锁的对象可以被持锁事务读取,但是不能被修改,其他事务也可以在上面再加s锁。
封锁协议:
一级封锁协议:
在事务修改数据的时候加x锁,直到事务结束(提交或者回滚)释放x锁。一级封锁协议可以有效的防止丢失更新,但是不能防止脏读不可重复读的出现。
二级封锁协议:
在一级封锁的基础上事务读数据的时候加s锁,读取之后释放。二级封锁协议可以防止丢失更新,脏读。不能防止不可重复读。
三级封锁协议:
在一级封锁的基础上事务读数据的时候加s锁,直到事务结束释放。二级封锁协议可以防止丢失更新,脏读,不可重复读。

         

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics