大家在工作中是如何处理事务隔离级别的?不同数据库间的移植如何解决?
本人感觉一般情况使用 Read Committed 就足够了,对于幻读现象,感觉很难在开发中遇到在一个事务中相同查询执行两次的情况;对于有需要处理重复读的地方,给表数据加 version 或者时间戳来处理,想听听朋友在在工作中在这方面的处理,谢谢!对于有帮助的回复本人都会给分。

解决方案 »

  1.   

    大并发情况下,会利用数据库本身锁定数据行,避免出现重复读之类的问题。一般情况下, 采用hibernate的乐观锁就足够避免脏读问题。
      

  2.   

    好象大多数情况下默认提供的就是Read Committed隔离,大多数情况下不会出现问题,在每天并发处理万笔交易的级别上平均每个月都有遇到一两笔的两次更新问题。而针对个别特殊的事务比如需要重复读的事务,除加状态标记及时间戳之外,尽量避开并发高峰期做后台自动处理。我的办法是日常工作时,相关的业务提交的只是一个请求,而晚间有一个专门的服务自动启动,串行执行当天提交的业务请求以求避免幻读。第二天针对失败的业务请求向业务员发出通知。
      

  3.   

    我所说的基本上是我们产品中的解决方法,因为我们产品属ERP类,对并发方面的要求没有电子商务类高,所以想听听别人的意见。