（我不认为你在使用ObjectDB。如果您编辑您的问题，并包括您正在使用JPA的特定数据库，您可能会得到更好的答案。
我不喜欢“乐观锁定”和“悲观锁定”这两个术语。我认为 * 乐观并发控制 * 和 * 悲观并发控制 * 更准确。锁是处理并发控制问题的最常用方法，但不是唯一的方法。（Date在《数据库系统简介》中关于并发性的章节大约有25页。）

• 事务管理 * 和 * 并发控制 * 的主题并不局限于数据的关系模型或SQL数据库管理系统（dbms）。事务隔离级别与SQL有关。
• pessibility concurrency control* 实际上只意味着当dbms * 开始 * 处理您的请求时，您希望dbms阻止其他事务访问 * 某些东西 *。行为取决于dbms供应商。不同的供应商可能通过锁定整个数据库、锁定某些表、锁定某些页或锁定某些行来阻止访问。或者，数据库管理系统可能会以其他方式阻止访问，而不直接涉及锁。

事务隔离级别是 SQL 试图解决并发控制问题的方式。事务隔离级别是在SQL标准中定义的。

• serializable* 事务隔离级别保证并发的、可序列化的事务的效果与以某种特定顺序一次运行一个事务的效果相同。保证描述了 * 效果 *--而不是任何特定类型的并发控制或锁定需要 * 实现 * 该效果。

Pessions锁定通常涉及对数据库的写锁，以便以安全和独占的方式进行更改。这通常通过执行select ... for update来完成。这将阻止或延迟其他连接对数据库中锁定的记录进行自己的select ... for update或更改，直到第一个连接的事务完成。
Serializable Isolation Level不需要关心更改，但确保在事务开始后，读取的结果将始终保持不变（除了事务本身的更改），直到该事务结束。为了支持这种“非MVCC”-DBMS必须在数据库中设置许多锁（在可串行化的连接读取的每个记录上），因此可能会非常阻碍并发性。

当数据库像Oracle、MySql-INNODB、MariaDB、Postgres那样提供MVCC时，也可以在不锁定的情况下实现相同的效果

隔离级别是对事务中哪些数据可查看的限制。
可序列化隔离如果在提交之前没有其他事务更改数据，则成功。固有的实现不应该产生死锁。

可串行化隔离的代价很高，因为要进行额外的检查以确保一致性。因此，使用较少限制的隔离，并且通过悲观/乐观锁定来同步对关键部分的访问。

Pessionallock是尝试锁定资源，否则交易失败。从事务的Angular 来看，这是Fail Fast模式，这是死锁的真正来源。这不是事务隔离，而是对并发访问的数据库内容的一种同步。
乐观锁根本不是锁，只是提交前的版本检查。