写作背景
最近一段时间一直在研究sso（基于cas），在马上接近尾声的时候集成又出现了问题，也许上天感觉这个程序员需要打击（积极的说法就是成长），言归正传：这次问题还是出现在事务不受控制！也许朋友会问，事务控制问题在这个配置横行的时代，可以说是妇孺皆知，何须再谈！那先让我叙述完今天我经历的悲剧，再议。
实现背景
完成单点登录的注册功能，涉及多个子系统（Mysql作为数据库），需要进行多个数据源进行操作，其中一个就是discuz 2.5论坛。
技术实现手段
Atomikos分布式事务+Spring JtaTransactionManager事务管理器+Spring 注解方式事务配置+JDBC （crud和存储过程）
病症表现
discuz 所在数据库的存储过程执行过程中异常或者错误，事务不回滚，但是其他子系统事务均回滚。
诊断过程
1、Atomikos组件不支持存储过程 验证方式：在存储过程中手动控制开启事务，执行过程中提示XAer—globel Transaction is actived ，表明Atomikos组件不是病因。清白
2、没有理由怀疑Spring JtaTransactionManager事务管理器,因为它太单纯，仅仅是一个配置。 清白
3、Spring 注解方式事务配置会不会存在问题，翻阅了官方doc和通过google确认，它也是 清白。
4、怀疑存储过程，这也是我今天纠结的地方，技术不好真可怕，后来翻阅了存储过程的相关文档和数据库事务相关文档后发现它本身也是一个原子操作，它也是 清白。
最后一个不清白的就是程序员本身了？不对，再审视一下，前面诸位都没有问题，可以抽象为代码级别的东西，换句话说：代码级别和配置上都没有问题。除了代码和配置之外还有什么会影响事务，确切的说是数据库事务。对，数据库！！！
打开mysql 数据库的客户端，直接在客户端执行存储过程，熟悉的参数设置好之后，开始执行，执行过程中出错，查看到之前的插入语句造成了影响，接近真理了。症结出在数据库，上升到高度就是引擎在作怪，打开插入语句影响的表惊奇的发现 ENGINE=MyISAM,大家都知道mysql MyISAM这种引擎方式是不支持事务的.
结论：出现事务问题考虑问题应该有两个层次，首先是你处在一个什么样的数据库引擎下（是否支持事务），其次审查一下你的代码你的配置信息是否正确（可以参考官方文档或者经典的开源实现）。
题外话：discuz 安装之后所有的表的引擎都是MyISAM值得大家留意。
