关于网友提出的“ 工作中有接触到事务隔离级别的朋友进”问题疑问，本网通过在网上对“ 工作中有接触到事务隔离级别的朋友进”有关的相关答案进行了整理，供用户进行参考，详细问题解答如下：
问题： 工作中有接触到事务隔离级别的朋友进描述:
大家在工作中是如何处理事务隔离级别的？不同数据库间的移植如何解决？
本人感觉一般情况使用 Read Committed 就足够了，对于幻读现象，感觉很难在开发中遇到在一个事务中相同查询执行两次的情况；对于有需要处理重复读的地方，给表数据加 version 或者时间戳来处理，想听听朋友在在工作中在这方面的处理，谢谢！对于有帮助的回复本人都会给分。
解决方案1:
好象大多数情况下默认提供的就是Read Committed隔离，大多数情况下不会出现问题，在每天并发处理万笔交易的级别上平均每个月都有遇到一两笔的两次更新问题。而针对个别特殊的事务比如需要重复读的事务，除加状态标记及时间戳之外，尽量避开并发高峰期做后台自动处理。我的办法是日常工作时，相关的业务提交的只是一个请求，而晚间有一个专门的服务自动启动，串行执行当天提交的业务请求以求避免幻读。第二天针对失败的业务请求向业务员发出通知。
解决方案2: 大并发情况下，会利用数据库本身锁定数据行，避免出现重复读之类的问题。
一般情况下， 采用hibernate的乐观锁就足够避免脏读问题。
复杂事务一般都用存储过程来做。重复读的一般就是加时间戳了，或者在存储过程中采用临时表来做。
你自己都差不多说完了。。。汗