记一次系统稳定性问题的分析处理过程(因CallContext使用不当而造成bug)

时间:2022-08-17 23:42:56

问题描述:

一个项目现场反馈,“差旅费类型的单据审批,在出现业务规则没满足的情况时(即业务报错,需要人机交互),审批仍然通过了”。从技术的角度上说,就是业务构件中的业务规则报错后,事务没有回滚。但是,维护的同事对事务回滚的代码增加了日志,通过日志发现事务回滚的代码显式的执行了,也没有出现任何异常。并且该问题可以反复重现,与并发也没有关系,单用户执行也会有问题。

分析过程:

接到这个问题时,我感觉很奇怪:从表面上看貌似跟该类单据的数据有关系,但从技术分析上看是与数据库事务控制有关系。按照道理上来讲,用户能够操作的业务定义类的数据,一般影响的是条件分支、业务判断等等,不应该能够影响到事务的执行。这时感觉有点蒙,突然有种无从下手的感觉。可能有人会说debug一下不就行了吗?是的,在我们面对demo程序、职责单一的模块、简单小系统的bug时,终极的排查方案可以使用debug调试。不过随着系统越来越复杂,业务层模块与底层平台之间会形成纵向依赖,模块、子系统甚至第三方系统之间会形成横向集成,此时debug往往显得力不从心。

经过几种简单的排查、推测后,我想到的是借助SqlServer Profiler分析问题:在跟踪事件中增加所有的脚本、异常及事务类的事件,在跟踪结果中分析各脚本与事务的匹配关系,本来应该回滚的SQL脚本对应的事务是在哪里commit?,显式回滚的事务又是从哪里开始的?这样就可以根据SQL脚本为线索快速定位到对应的代码模块。呵呵,看起来很快就要出结果了。马上与现场人员沟通跟踪方案,结果该客户使用的是Oracle数据库,糟糕,目前尚未发现Oracle对相对应的工具!虽然v$sql等性能视图可以查询对应的SQL,但至关重要的是事务与脚本匹配关系如何获得呢?好像又陷入了未知……

查看Oracle的日志,没有发现错误、异常信息,难道事务中包含DDL脚本?单用户场景下清空shared_pool重现问题,没有发现DDL脚本。难道事务有问题?于是我在事务回滚的代码之前加一个简单的Insert脚本,结果该insert操作被回滚了。此时突然发现,有一个SQL在业务出现异常后,按道理说是不应该被执行的,但目前也被持久化到数据库了。也就是说如果找到了执行该SQL的代码,应该离原因就比较近了。马上想到一个工具------RedGate Performance Profiler。

以下是RedGate的跟踪情况,从调用堆栈上看,该SQL的代码是异步执行的??很是奇怪,异步线程为什么会触发父线程的持久化操作?

记一次系统稳定性问题的分析处理过程(因CallContext使用不当而造成bug)

调阅对应的程序代码发现,果然是异步执行的,分支中判断了一个Contex的值。需要进一步查阅代码。。。

记一次系统稳定性问题的分析处理过程(因CallContext使用不当而造成bug)

问题解决:

打开这段代码一看就比较清楚了,这里使用了CallContext的LogicalGet/Set(即创建的子线程会复制父线程的上下文变量),经确认此处不需要这种“继承关系”,改为CallContext.GetData/SetData后问题解决。以后再使用时一定注意。

记一次系统稳定性问题的分析处理过程(因CallContext使用不当而造成bug)

关于CallContext,微软给出的说明很简单:

CallContext 是类似于方法调用的线程本地存储区的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽。数据槽不在其他逻辑线程上的调用上下文之间共享。当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中。

https://msdn.microsoft.com/zh-cn/library/System.Runtime.Remoting.Messaging.CallContext(v=vs.100).aspx