当你解决故障的时候,一定要防止对方对问题提前下结论,如果对方局部的证明是能证明结论是正确的,那从全局来看呢?不要在二手信息上深入讨论,不要用二手信息作为重要依据。
最近排查一个奇怪的问题,第一个编程式事务开启不提交,不回滚;第二个声明式事务也提交不成,并且trx_mysql_thread_id一样。
根本原因在于这两次,getSqlSession的时候,获取的SqlSession一样。
第二次复用了第一次的SqlSession会话:autoCommit为false 所以第二次也是执行失败的。
为什么会复用?第一次SqlSessionHolder 里面hold住线程的SqlSession,没有remove。
SqlSession 线程安全为什么会出现复用了第一次会话?因为线程池里面的线程可以复用。
Spring事务和数据库事务啥关系,归根结底Spring事务会把事务翻译成数据库可执行的事务脚本,如:start,commit,rollback。
那从整体来看,需要怎么故障改进?
第一,优化故障获知和故障定位的时间。
从故障发生到我们知道的时间是否可以优化得更短?
定位故障的时间是否可以更短?
有哪些地方可以做到自动化?
第二,优化故障的处理方式。
故障处理时的判断和章法是否科学,是否正确?
故障处理时的信息是否全透明?
故障处理时人员是否安排得当?
第三,优化开发过程中的问题。
Code Review 和测试中的问题和优化点。
软件架构和设计是否可以更好?
对于技术欠债或是相关的隐患问题是否被记录下来,是否有风险计划?
第四,优化团队能力。
如何提高团队的技术能力?
如何让团队有严谨的工程意识?
做个简短的总结:循序渐进的让故障定位时间变短,持续改善,不要出现好像又是人品的问题,莫名的日了狗,不存在的,归根结底是自己的基础理论修养不够。关于严谨程度,是工程师很重要的品质。
希望你有自由讨论的习惯,有肯于他人调和的性格,有在真理面前,自甘让步的气量,有据理力争而不伤和气的胸襟。