4
回答
追问 ssh框架中大事务的解决办法?
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

我的问题:http://www.oschina.net/question/35243_39454#AnchorAnswer196251

看了你的回复,想在说一些情况

举个例子吧,我现在有两个大事物,每个事物里都对多张表进行update操作,我是否要注意这些update的顺序,如:

事物1的update顺序:update A表,update B表,update C表

事物2的update顺序:update C表,update A表,update B表

我分析了一下,并发多的时候,这种情况下应该会出现死锁的问题

是不是这种情况就是你说的时间点问题

 

盼复!

<无标签>
举报
melnnyy
发帖于6年前 4回/215阅
共有4个答案 最后回答: 6年前

你说这种情况应该没有问题

事务1在执行update c,这个时候所有对c的update都会等待,直到事务1提交。这个应该没问题的

你可以再看看一个事务里面包含了两个update A表的情况

事务A开始

        do something

        update a

        do something

        update b

           update a

事务a结束

这样就挂了

引用来自“胡咧咧”的答案

你说这种情况应该没有问题

事务1在执行update c,这个时候所有对c的update都会等待,直到事务1提交。这个应该没问题的

你可以再看看一个事务里面包含了两个update A表的情况

事务A开始

        do something

        update a

        do something

        update b

           update a

事务a结束

这样就挂了

真有这样的情况,但是我的每次update操作最后都调用了HibernateTemplate的flush了

如果向你说的这种情况,理论上是不是只要执行到这里就会死锁呢?

但现在的状况是,不是频繁死锁,而是偶尔死锁,并且在并发量不大的时候也会

这应该就是并发导致的死锁,你要分析一下程序在并发场景下会如何执行,会出现什么情况

我建议update之前去做记录锁操作

select * from A where id = x for update wait 5

如果锁不到记录就报错,证明有线程在做类似的操作,本次操作就不用做了。

不知适合你的场景吗?

引用来自“胡咧咧”的答案

这应该就是并发导致的死锁,你要分析一下程序在并发场景下会如何执行,会出现什么情况

我建议update之前去做记录锁操作

select * from A where id = x for update wait 5

如果锁不到记录就报错,证明有线程在做类似的操作,本次操作就不用做了。

不知适合你的场景吗?

我改一下,再观察一段时间看看!

谢谢啊!!!

顶部