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

问题描述：

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

分析过程：

接到这个问题时，我感觉很奇怪：从表面上看貌似跟该类单据的数据有关系，但从技术分析上看是与数据库事务控制有关系。按照道理上来讲，用户能够操作的业务定义类的数据，一般影响的是条件分支、业务判断等等，不应该能够影响到事务的执行。这时感觉有点蒙，突然有种无从下手的感觉。可能有人会说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的代码是异步执行的？？很是奇怪，异步线程为什么会触发父线程的持久化操作？

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

问题解决：

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

关于CallContext，微软给出的说明很简单：

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

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