问题描述
请问在事务级别上怎么设置比较好！都是在什么操作中设置，哪一个级别好一点！需不需要在update，delete select 方法上加上synchronized呢？问题补充：要是对数据完整性要求比较高，比如政府系统，在线人数多，操作频繁，应该如何去设置事务的级别？感觉加上synchronized会影响效率，不加有怕会出现不正确数据。如何避免呢？要是把级别设置最高！会不会好一点。还是怎么做比较好一点！
解决方案
对于同时运行的多个事务，当这些事务访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种并发问题，这些并发问题可归纳为以下几类： A.第一类丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖。 B.脏读：一个事务读到另一个事务为提交的更新数据。 C.虚读：一个事务读到另一个事务已提交的新插入的数据。 D.不可重复读：一个事务读到另一个事务已提交的更新数据。 E.第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据。 数据库系统提供了四种事务隔离级别供用户选择： A.Serializable（串行化）：一个事务在执行过程中完全看不到其他事务对数据库所做的更新。 B.Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，但是不能看到其他其他事务对已有记录的更新。 C.Read Commited（读已提交数据）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录，而且能看到其他事务已经提交的对已有记录的更新。 D.Read Uncommitted（读未提交数据）：一个事务在执行过程中可以拷打其他事务没有提交的新插入的记录，而且能看到其他事务没有提交的对已有记录的更新。 隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以有优先考虑把数据库系统的隔离级别设为Read Commited，它能够避免脏读，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。 当数据库系统采用read Commited隔离级别时，会导致不可重复读喝第二类丢失更新的并发问题，可以在应用程序中采用悲观锁或乐观锁来避免这类问题。从应用程序的角度，锁可以分为以下几类： A.悲观锁：指在应用程序中显示的为数据资源加锁。尽管能防止丢失更新和不可重复读这类并发问题，但是它会影响并发性能，因此应该谨慎地使用。 B.乐观锁：乐观锁假定当前事务操作数据资源时，不回有其他事务同时访问该数据资源，因此完全依靠数据库的隔离级别来自动管理锁的工作。应用程序采用版本控制手段来避免可能出现的并发问题。 这样说可以吗？你可以根据你的实际的系统运行情况选定事务级别啊
解决方案二：
事务级别一般默认就可以啊，处除非你有什么特殊需要update，delete select 方法上加上synchronized这个要看你做什么东西了一般对多个表大量数据的长时间操作加上synchronized比如说在系统里对数据库的导入和导出