日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材_。
事实上,这篇文章并没有什么排查过程。但这个问题却又是笔者经常遇到的。
笔者仅仅是想阐述一下当我们在事务Commit报错时候,数据库中的数据并不一定会是我们以为的回滚状态。笔者举个例子:
在这种情况下,很明显的DB的数据肯定是处于已经提交的状态。而如果App认为是回滚状态,并基于这个信息去做操作的话,很明显会导致数据不一致。
可能有人会问了,是不是仅仅是IO异常或者超时异常才会出现这种不一定回滚的问题呢?这里还真不一定,笔者在一次Case中,就发现Oracle在commit的时候返回死锁异常时候,数据库内部的commit竟然也成功了!这就牵涉到数据库内部的处理了。
事实上,由于数据库保证了原子性。所以我们在遇到这种情况时候,需要从数据库中重建状态,而不是依赖现在应用里面的信息。所以遇到异常直接将流程结束,然后等定时任务等补单操作是个比较简单安全的做法。
当然,数据库中重建状态时候,也要考虑到上一个相应的commit还在commit的过程中,只不过这个commit非常慢而已。由于我们更新数据或者最终判断的时候往往会锁住数据,而数据库一般都是采用了二阶段锁(S2PL)。
在上一个commit成功提交之后,我们对相应数据的操作才会执行下去。所以只要小心的控制好锁的范围,数据一致性还是能保证的。
Commit报错但事务并没有回滚,这个虽然有点反直觉,但这确是在产线真实存在的,尤其在数据库压力大的时候极易出现。这个坑在我们编写代码的时候需要牢记!