标签：出现 读取数据 mit href 图片 技术 乐观锁 ted 应用程序
事务隔离级别：
1.更新遗失(Lost update)
两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
基本上就是指某个事务对字段进行更新的信息，因另一个事务的介入而遗失更新效力。举例来说，若某个字段数据原为ZZZ，用户A、B 分别在不同的时间点对同一字段进行更新事务，如下图：
单就用户A 的事务而言，最后字段应该是OOO，单就用户B 的事务而言，最后字段应该是ZZZ。在完全没有隔离两者事务的情况下，由于用户B 撤销操作时间在用户A 确认之后，因此最后字段结果会是ZZZ，用户A看不到他新确认的OOO 结果，用户A 发生更新遗失问题。
如果要避免更新遗失问题，需要设置隔离级别为“可读取未确认”（Read Uncommitted），如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。
该隔离级别可通过“排他写锁”实现。JDBC 可通过Connection 的setTransactionIsolation()设置为TRANSACTION_UNCOMMITTED 来提示数据库指定此隔离行为。
实现后如下图:
提示数据库“可读取未确认”的隔离层次之后，数据库至少得保证事务能避免更新遗失问题，通常这也是具备事务功能的数据库引擎会采取的最低隔离层级。不过这个隔离层级读取错误数据的机率太高，一般默认不会采用这种隔离级别。
2.脏读（Dirty read）
两个事务同时进行，其中一个事务更新数据但未确认，另一个事务就读取数据，就有可能发生脏读问题，也就是读到所谓脏数据、不干净、不正确的数据。如下图：
如果要避免脏读问题，可以设置隔离层级为“可读取确认”(Read committed)。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。也就是事务读取的数据必须是其他事务已确认的数据。JDBC 可通过Connection 的setTransactionIsolation()设置为TRANSACTION_COMMITTED 来提示数据库指定此隔离行为。
实现后如下图所示：
提示数据库“可读取确认”的隔离层次之后，数据库至少得保证事务能避免脏读与更新遗失问题。
3.无法重复的读取（Unrepeatable read）
某个事务两次读取同一字段的数据并不一致。如下图：
如果要避免无法重复的读取问题， 可以设置隔离层级为“可重复读取”(Repeatable read)，这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。也就是同一事务内两次读取的数据必须相同。JDBC 可通过Connection 的setTransactionIsolation()设置为TRANSACTION_REPEATABLE_READ 来提示数据库指定此隔离行为。
实现后如下图所示：
在数据库上这个做法影响性能较大，另一个基本做法是事务正在读取但尚未确认前，另一事务会在暂存表格上更新。提示数据库“可重复读取”的隔离层次之后，数据库至少得保证事务能避免无法重复读取、脏读与更新遗失问题。
4.幻读(Phantom read)
同一事务期间，读取到的数据笔数不一致。例如，事务A 第一次读取得到五笔数据，此时事务B 新增了一笔数据，导致事务B 再次读取得到六笔数据。
如果隔离行为设置为可重复读取，但发生幻读现象，可以设置隔离层级为“可循序”(Serializable)，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。也就是在有事务时若有数据不一致的疑虑，事务必须可以按照顺序逐一进行。JDBC 可通过Connection 的setTransactionIsolation()设置为TRANSACTION_SERIALIZABLE 来提示数据库指定此隔离行为。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
转自博客：https://www.cnblogs.com/renchunxiao/p/3297612.html
标签：出现 读取数据 mit href 图片 技术 乐观锁 ted 应用程序
原文地址：https://www.cnblogs.com/dpqq/p/10732426.html
