建立一个 Derby 日历，第 3 部分: 使用事务和锁定（上）

核心提示： （第三种类型的锁，更新（update）锁，建立一个 Derby 日历，第 3 部分: 使用事务和锁定（上）(10)，是这两种类型的组合，） 提交或回滚事务将释放该事务所有的锁，数据在查看的时候，有可能被其他事务修改， 锁定范围范围在锁定中很重要，Derby 提供了两种主要的锁定范围：行锁定与表锁

（第三种类型的锁，更新（update）锁，是这两种类型的组合。）

提交或回滚事务将释放该事务所有的锁。

锁定范围

范围在锁定中很重要。Derby 提供了两种主要的锁定范围：行锁定与表锁定。

比如，假设要更新 Event 表中的一行。如果数据库使用行锁定，该事务就对这一行拥有独占锁。其他事务不能选择该行（因为得不到共享锁），但是可以选择表中的其他行或者插入和更新其他数据。

另一方面，如果数据库使用表锁定，更新这一条记录后，就对整个表拥有独占锁，任何人都不能对该表执行 select 语句，更不用说修改数据了。

显然，如果多个会话并发使用一个系统，那么行锁定的性能更好一些，这也是 Derby 默认使用的方式。但是如果堆积了很多锁，以至于使用表锁定更有效，Derby 就会自动切换。可以用 derby.storage.rowLocking 属性控制切换的阈值。比如，在应用程序开发的初期阶段，前面已经看到，表差不多是空的，Derby 几乎总是选择表锁定。只有加入大量数据之后才能看到行锁定。

隔离级别

现在已经了解了不同类型的异常和 Derby 用于防止出现这些异常的锁。使用锁的方式决定了事务的隔离级别。

Derby 事务可存在于以下四种隔离级别中：

TRANSACTION_READ_UNCOMMITTED

使用这种隔离级别的事务不请求锁。换句话说，如果执行更新，其他事务能看到未提交的数据。这种情况下、脏读、不可能重复读和虚读都是可能的。无论使用表锁还是行锁都没有关系，因为事务根本不请求锁。

TRANSACTION_READ_COMMITTED

这种模式下，更新（或删除、插入）数据时数据库请求独占锁，可以防止脏读，因为一旦锁定，其他事务就不能得到数据共享锁。另一方面，选择时数据库只请求共享锁。数据在查看的时候，有可能被其他事务修改，因此仍然可能出现不可重复读（另一个事务更新了查看的行）和虚读（另一个事务添加了本来应该能够看到的数据）。