JDBC 事务级别

Question

请问在事务级别上怎么设置比较好！

都是在什么操作中设置，哪一个级别好一点！

需不需要在update，delete select 方法上加上synchronized呢？

[b]问题补充：[/b]
要是对数据完整性要求比较高，
比如政府系统，
在线人数多，操作频繁，应该如何去设置事务的级别？
感觉加上synchronized会影响效率，不加有怕会出现不正确数据。
如何避免呢？
要是把级别设置最高！会不会好一点。
还是怎么做比较好一点！

Answer 1

对于同时运行的多个事务，当这些事务访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可归纳为以下几类：

A.第一类丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖。

B.脏读：一个事务读到另一个事务为提交的更新数据。

C.虚读：一个事务读到另一个事务已提交的新插入的数据。

D.不可重复读：一个事务读到另一个事务已提交的更新数据。

E.第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据。

数据库系统提供了四种事务隔离级别供用户选择：

A.Serializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新。

B.Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他其他事务对已有记录的更新。

C.Read Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新。

D.Read Uncommitted（读未提交数据）：一个事务在执行过程中可以拷打其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以有优先考虑把数据库系统的隔离级别设为Read Commited，它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

当数据库系统采用read Commited隔离级别时，会导致不可重复读喝第二类丢失更新的并发问题，可以在应用程序中采用悲观锁或乐观锁来避免这类问题。从应用程序的角度，锁可以分为以下几类：

A.悲观锁：指在应用程序中显示的为数据资源加锁。尽管能防止丢失更新和不可重复读这类并发问题，但是它会影响并发性能，因此应该谨慎地使用。

B.乐观锁：乐观锁假定当前事务操作数据资源时，不回有其他事务同时访问该数据资源，因此完全依靠数据库的隔离级别来自动管理锁的工作。应用程序采用版本控制手段来避免可能出现的并发问题。

[color=orange]这样说可以吗？你可以根据你的实际的系统运行情况选定事务级别啊[/color]