大家如何解决长事务并发控制的问题？
数据库表写的并发控制，一般通过版本号或者时间戳进行冲突判定。但对于冲突后的操作如何处理？放弃？？
那给业务操作带来很大的不方便性。
所以我最后还是采用主表中带标志位来进行表的锁定和解锁，人工避免表的并发访问。这样又带来新的问题：
1：数据库表的解锁很难控制，标志位的操作很繁琐。
2：复杂业务（主表不止一个）时很容易出现表的死锁
有过相关经验的，进来介绍下。
大家难道都是用version进行并发控制？那如果一个业务操作要10多分钟，等用户执行的时候再弹出
“所作记录已被修改，输入信息将作废”的警告，这样的系统设计也太烂了吧。
在这多说几句,现在很多人一说起新技术、新框架就眉飞色舞，仿佛用了新的技术，好的框架一切问题
就引刃而解一样。中国现在并没有到技术引领产业的时候，而是还在处作产品作行业的环境。技术是思想的体现。
没有好的新的思想而单纯研究技术，只是在浪费时间。不如想想如何整合业务需求，如何更好的业务建模好了。
与其花时间研究一堆思想类似的框架，不如花时间作一个更切合用户需求的产品来的有意义。
使用JTA， 更长的使用JMS
你提的问题本身就是业务相关的。跟技术有什么关系。
》》对于冲突后的操作如何处理？放弃？？
这还不是根据你的具体业务需求做决定。你要搞个“乐观锁”，那就用类似version的解决。如果你怕用户麻烦，需要完全锁定，那就用select * from update把表锁定了。这些细节的东西，根本只能具体情况具体分析，自己都不知道要做什么。有什么资格评价所谓的新框架新技术。
技术就鸡吧那么几种实现。自己不会根据实际情况来使用。骂别人学习新技术有个鸟用
> 技术就鸡吧那么几种实现。自己不会根据实际情况来使用。
> 骂别人学习新技术有个鸟用
呵呵