java持久性与安全性_Java持久性锁定初学者指南

java持久性与安全性

隐式锁定

在并发理论中，锁定用于保护可变共享数据免受危险数据完整性异常的影响。因为锁管理是一个非常复杂的问题，所以大多数应用程序都依赖于其数据提供程序隐式锁技术。

将整个锁定职责委托给数据库系统既可以简化应用程序开发，又可以防止诸如死锁之类的并发问题。死锁仍然可能发生，但是数据库可以检测并采取安全措施（任意释放两个竞争锁之一）。

大多数数据库系统使用共享（读取）和排他（写入）锁，这归因于特定的锁定元素（行，表）。尽管SQL标准要求物理锁定，但是悲观的方法可能会阻碍可伸缩性。

现代数据库已实现了轻量级锁定技术，例如多版本并发控制。

隐式数据库锁定隐藏在事务隔离级别配置的后面。每个隔离级别都带有预定义的锁定方案，旨在防止某些数据完整性异常集。

READ COMMITTED对当前事务修改的数据使用查询级共享锁和排他锁。 REPEATABLE READ和SERIALIZABLE在读取时使用事务级共享锁，在写入时使用互斥锁。

如果数据库锁定足以用于批处理系统，则多请求Web流将跨越多个数据库事务。对于长时间的对话，逻辑（乐观）锁定机制更为合适。

与对话级别的可重复读取存储结合使用，乐观锁定可以确保数据完整性，而无需牺牲可伸缩性。

JPA支持开放式锁定和持久性上下文可重复读取，使其非常适合实现逻辑事务。

虽然对于大多数应用程序并发控制要求，隐式锁定可能是最佳选择，但有时您可能需要更细粒度的锁定策略。

大多数数据库系统都支持查询时排他锁定指令，例如SELECT FOR UPDATE或SELECT FOR SHARE 。因此，我们可以使用较低级别的默认隔离级别（READ COMMITTED），同时为特定事务方案请求共享或排他锁。

大多数乐观锁定实现只验证修改后的数据，但是JPA也允许显式乐观锁定。

作为数据库抽象层，JPA可以从基础RDBMS提供的隐式锁定机制中受益。对于逻辑锁定，JPA还提供了可选的自动实体版本控制机制。

JPA支持以下操作的显式锁定：

LockModeType包含以下乐观和悲观锁定模式：

锁定模式类型	描述
没有	在没有显式锁定的情况下，应用程序将使用隐式锁定（乐观或悲观）
乐观的	始终在事务提交时发出版本检查，因此确保乐观锁定可重复读取。
读	与OPTIMISTIC相同。
OPTIMISTIC_FORCE_INCREMENT	始终增加实体版本（即使实体不变），并在事务提交时发出版本检查，从而确保乐观锁定可重复读取。
写	与OPTIMISTIC_FORCE_INCREMENT相同。
PESSIMISTIC_READ	获取共享锁以防止任何其他事务获取PESSIMISTIC_WRITE锁。
PESSIMISTIC_WRITE	获取排他锁以防止任何其他事务获取PESSIMISTIC_READ或PESSIMISTIC_WRITE锁。
PESSIMISTIC_FORCE_INCREMENT	获取数据库锁以防止任何其他事务获取PESSIMISTIC_READ或PESSIMISTIC_WRITE锁，并且在提交事务时会增加实体版本。

JPA 2.0定义了javax.persistence.lock.scope属性，采用以下值之一：

NORMAL由于对象图可以跨越多个表，因此显式的锁定请求可能会传播到多个表（例如，联接继承，辅助表）。由于整个实体关联的行都被锁定，因此多对一和一对-一对一的外键也将被锁定，但不会锁定另一侧父级关联。此范围不会传播到子级集合。
扩展显式锁将传播到元素集合和联结表，但不会锁定实际的子实体。该锁仅在防止幻像读取或更改实际的子实体状态的同时用于防止删除现有的子实体。

JPA 2.0还引入了javax.persistence.lock.timeout属性，使我们能够配置锁定请求在引发PessimisticLockException之前将等待的时间（毫秒）。

Hibernate支持所有JPA锁定模式和一些其他特定的锁定选项。与JPA一样，可以为以下操作配置显式锁定：

LockModeConverter负责映射JPA和Hibernate锁定模式，如下所示：

Hibernate锁定模式	JPA LockModeType
没有	没有
乐观的读	乐观的
OPTIMISTIC_FORCE_INCREMENT 写	OPTIMISTIC_FORCE_INCREMENT
PESSIMISTIC_READ	PESSIMISTIC_READ
PESSIMISTIC_WRITE 升级 UPGRADE_NOWAIT UPGRADE_SKIPLOCKED	PESSIMISTIC_WRITE
PESSIMISTIC_FORCE_INCREMENT 力	PESSIMISTIC_FORCE_INCREMENT