某日,DBA反映线上数据库报警,检测到死锁,跟踪到发生死锁等待的两条SQL语句分别为:
以及
回忆大学里的课程,死锁一般是由于资源互相占用并且无法释放导致的,因此重点排查IBANK中相关数据表的操作,发现在saveImg和moveImg两个方法中存在以下逻辑
众所周知,死锁的四要素
1、互斥条件
2、请求与保持条件
3、不剥夺条件
4、循环等待条件
可以看出,前三条的都是事务引起的,因此大家以后要慎用事务处理或者设置事务级别,在确实需要使用事务的时候,请打破循环条件(保持update语句调用顺序的一致性,而非首尾相连的颠倒次序)
和同事聊起事务这类死锁问题的时候,发觉电子支付时这类情况比较常见,比如账户A转账100元到账户B,涉及到事务性的操作(A-100,B+100),如果牵涉到反复倒帐的情况,就有可能发生死锁,据说当初解决的方法,就是在事务当中,统一按照id大小进行处理,即都是先小ID处理,在大ID处理,简单优雅地解决了此类问题
- UPDATE WP_IMAGE_SORT SET GMT_MODIFIED = SYSDATE,IMAGE_IDS = #imageIds# || IMAGE_IDS WHERE MEMBER_ID = #memberId# AND ALBUM_ID = #albumId#
以及
- update WP_ALBUM set GMT_MODIFIED = sysdate,
- image_count = (select count(*) from wp_image where album_id= #id# and STATUS <![CDATA[<>]]> 'deleted')
- where id = #id#
- and member_id = #memberId#
回忆大学里的课程,死锁一般是由于资源互相占用并且无法释放导致的,因此重点排查IBANK中相关数据表的操作,发现在saveImg和moveImg两个方法中存在以下逻辑
- saveImg
- {
- ……
- //Transaction start
- appendImageSort(memberId, album.getId(), imgId.longValue());
- ……
- winportAlbumDAO.updateAlbumImageCountAndLastModified(album.getId(), album.getMemberId());
- //Transaction end
- ……
- }
- moveImg
- {
- ……
- //Transaction start
- winportAlbumDAO.updateAlbumImageCount(srcAlbumDO.getId(), memberId);
- ……
- imageBO.appendImageSort(memberId, targetAlbumDO.getId(), ids);
- //Transaction end
- ……
- }
众所周知,死锁的四要素
1、互斥条件
2、请求与保持条件
3、不剥夺条件
4、循环等待条件
可以看出,前三条的都是事务引起的,因此大家以后要慎用事务处理或者设置事务级别,在确实需要使用事务的时候,请打破循环条件(保持update语句调用顺序的一致性,而非首尾相连的颠倒次序)
和同事聊起事务这类死锁问题的时候,发觉电子支付时这类情况比较常见,比如账户A转账100元到账户B,涉及到事务性的操作(A-100,B+100),如果牵涉到反复倒帐的情况,就有可能发生死锁,据说当初解决的方法,就是在事务当中,统一按照id大小进行处理,即都是先小ID处理,在大ID处理,简单优雅地解决了此类问题