Spring 事务隔离级别
@Transactional(propagation = Propagation.REQUIRED)
- spring的事务需要设置到业务方法上(事务边界定义到Facade类上),不要添加到Dao上
3、了解事务的集中传播忒性
1、PROPAGATION_REQUIRED:如果存在一个事务,则支持当前事务。如果没有事务则开启。
2、PROPAGATION_SUPPORTS:如果存在一个事务,支持当前事务。如果没有事务,则非事务的执行。
3、PROPAGATION_MANDATORY:如果已经存在一个事务,支持当前事务。如果没有一个活动的事务,则抛出异常。
4、PROPAGATION_REQUIRES_NEW:总是开启一个新的事务。如果一个事务存在,则将这个存在的事务挂起。
5、PROPAGATION_NOT_SUPPORTED:总是非事务地执行,并挂起任何存在的事务。
6、PROPAGATION_NEVER:总是非事务地执行,如果存在一个活动事务,则抛出异常。
7、 PROPAGATION_NESTED:如果一个活动的事务存在,则运行在一个嵌套的事务中,如果没有活动事务,则按TransactionDefinition.PROPAGATION_REQUIRED属性执行
4、Spring事务的隔离级别
1、 ISOLATION_DEFAULT: 这是一个PlatfromTransactionManager默认的隔离级别,使用数据库默认的事务隔离级别。
2、ISOLATION_READ_UNCOMMITTED:这是事务最低的隔离级别,它允许另外一个事务可以看到这个事务未提交的数据。
3、ISOLATION_READ_COMMITTED:保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。
4、ISOLATION_REPEATALBE_READ: 这种事务隔离级别可以防止脏读,不可重复读。但是可能出现幻想读。它除了保证一个事务不能读取另外一个事务未提交的数据外,还保证了避免下面的情况产生(不可重复读)。
5、ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读,不课重复读外,还避免了幻想读。
高并发下的分布式锁
- 数据库锁
- redis
- zookeeper
` 基于异常
基于相互监听(性能比较高,但是占用资源)
A系统给B系统转100块钱,如何实现
数据如何保证一致性,性能优化 CAS锁
注解事务用的不好,影响性能
解决办法
1)编程式事务,代码块加事务
new TransactionCallBack
2)状态机的乐观锁
orderItem.setVersion(0)
orderDao.updateOderInfo(orderItem)
增加version 版本号,默认为0 修改一次则为1 当再次进行修改,条件不整体
update order_info set orderStatus=#{orderStatus}, version=version+1
where orderId=#{orderId} AND version=#{version}