数据库死锁:
锁分类:
S 共享锁
U 更新锁
X 排它锁
锁兼容性:
锁 S U X
S Y Y N
U Y N N
X N N N
死锁场景:
单表:
场景1: T1, T2 X锁都加不上.
T1 T2
S S
X X
场景2: T1 X锁加不上, T2 U锁加不上.
T1 T2
U S
X U
多表(A,B):
场景3: T1, T2 X锁都加不上.
T1 T2
S(A) S(B)
X(B) X(A)
场景4: T1, T2 S锁都加不上.
T1 T2
X(A) X(B)
S(B) S(A)
场景5: T1, T2 U锁都加不上.
T1 T2
U(A) U(B)
U(B) U(A)
场景6: T1 S锁加不上,T2 U锁加不上.
T1 T2
U(A) X(B)
S(B) U(A)
场景7: T1 S锁加不上,T2 X锁加不上.
T1 T2
S(A) X(B)
S(B) X(A)
场景8: T1 U锁加不上,T2 X锁加不上.
T1 T2
S(A) U(B)
U(B) X(A)
..............
乐观锁:
..............
[url]http://ajava.org/course/open/5391.html[/url]
乐观锁是解决并发更新丢失问题,较悲观锁而言性能更好.
关于乐观锁如何进行版本控制, Hibernate 应该是更新时同步了缓存的, 因此在提交之前,做个切点判断实体的版本号是否大于当前数据库的版本号, 就可以抛出异常了. 没看源码,瞎猜的.
在看了代码后,发现是执行更新后,根据返回影响的行数来决定是否抛出异常的,与缓存没关系.
锁分类:
S 共享锁
U 更新锁
X 排它锁
锁兼容性:
锁 S U X
S Y Y N
U Y N N
X N N N
死锁场景:
单表:
场景1: T1, T2 X锁都加不上.
T1 T2
S S
X X
场景2: T1 X锁加不上, T2 U锁加不上.
T1 T2
U S
X U
多表(A,B):
场景3: T1, T2 X锁都加不上.
T1 T2
S(A) S(B)
X(B) X(A)
场景4: T1, T2 S锁都加不上.
T1 T2
X(A) X(B)
S(B) S(A)
场景5: T1, T2 U锁都加不上.
T1 T2
U(A) U(B)
U(B) U(A)
场景6: T1 S锁加不上,T2 U锁加不上.
T1 T2
U(A) X(B)
S(B) U(A)
场景7: T1 S锁加不上,T2 X锁加不上.
T1 T2
S(A) X(B)
S(B) X(A)
场景8: T1 U锁加不上,T2 X锁加不上.
T1 T2
S(A) U(B)
U(B) X(A)
..............
乐观锁:
..............
[url]http://ajava.org/course/open/5391.html[/url]
乐观锁是解决并发更新丢失问题,较悲观锁而言性能更好.
关于乐观锁如何进行版本控制, Hibernate 应该是更新时同步了缓存的, 因此在提交之前,做个切点判断实体的版本号是否大于当前数据库的版本号, 就可以抛出异常了. 没看源码,瞎猜的.
在看了代码后,发现是执行更新后,根据返回影响的行数来决定是否抛出异常的,与缓存没关系.