Hibernate与数据库事务

Hibernate异常

1.Hibernate5/JPA抛出的异常都是RuntimeException异常.
2.如果一个持久化上下文运行在一个JTA事务下,那么抛出的大部分JPA异常(严重异常)会自动将当前事务状态设置为Rollback除了几个异常,分别是(NoResultException;NonUniqueResultException;QueryTimeoutException;LockTimeoutException),这些异常不会将事务状态设为Rollback,但你还是可以捕获这些异常,并决定是手动回滚还是尝试异常恢复.

持久化上下文提供了可重复读的保证(多次读取同一条记录,该记录不变),如果不需要防止幻读,可以使用RC隔离级别.(Mysql RR无幻读).

使用@Version启用乐观版本控制,即first commit success.其他提交将抛出OptimisticLockException.

@Version
protected long version;

InnoDB隔离级别与存在的问题

|问题|RC快照读|RC当前读|RR快照读|RR当前读|

|--|--|--|

|不可重复读|✔|✘|✘|✘|

|幻读|✔|✔|✘|✘|

由于RC快照读出现的不可重复读问题可以由HIbernate一级缓存解决，所以如果不需要解决幻读问题，可以使用RC隔离级别。

RC当前读与RR当前读的最大区别，就是RR当前读使用了GAP锁（解决了幻读问题），这二者都使用了X锁。所以都没有不可重复读的问题（对一条数据加了行锁）。

RC当前读可能出现查询条件相同，但是两次返回结果不同的情况，RR当前读由于加了GAP锁，所以不存在这种通过insert/update改变某条数据使得符合条件的数据变更的情况存在。即，如果需要在一个事务中对一个范围查询返回一致的查询结果，那么应该使用RR，对一条唯一数据返回一致结果则使用RC当前读即可。

基于当前读（for update）的结果进行数据更新，则RR/RC都不存在丢失更新的问题，这相当于使用了悲观锁，但基于快照读的结果进行数据更新，则RR/RC都存在第二类丢失更新的问题，所以基于快照读更新数据需要额外的乐观锁保障（Hibernate的@Version）。（在某些情况下，悲观锁根本不能被应用到实际项目中，比如web的请求无状态性质，导致其查询与更新的操作不可能在一个事务内完成，这时候的更新丢失问题就只能通过乐观锁解决了）。