使用事务的竞争条件

Question

我有这笔交易：

em.getTransaction().begin();
{
    final Payment payment = em.find(Payment.class, id);
    if (payment.status != Status.INIT)
        throw new IllegalStateException("Cannot set to PAID, is not INIT but " + status);

    payment.status = Status.PAID;

}
em.getTransaction().commit();
log.info("Payment " + id + " was paid");

但是，正如您在此处看到的，事务不会阻止竞争条件：

[11:10:18.265] INFO  [PaymentServlet] [MSP] Status COMPLETED 
[11:10:18.265] INFO  [PaymentServlet] Payment c76f9e75-99d7-4721-a8ac-e3a638dd8317 was paid 
[11:10:18.267] INFO  [PaymentServlet] [MSP] Status COMPLETED 
[11:10:18.267] INFO  [PaymentServlet] Payment c76f9e75-99d7-4721-a8ac-e3a638dd8317 was paid 

两次付款设置为PAID。我的异常没有抛出，也没有回滚什么的。

我做错了什么？

Answer 1

您需要使用乐观锁定。乐观锁定是冲突更新很少发生的地方，因此可以在偶然事务发生时回滚它。悲观锁定导致数据库在对象使用时对其进行锁定，从而有效地将所有内容单线程处理并可能导致性能问题。更详细的解释见http://en.wikibooks.org/wiki/Java_Persistence/Locking#JPA_2.0_Locking。

要解决这里的问题，你应该在 Payment 中添加一个字段（传统的声明是 private Long 版本）并给它 JPA @Version 注解。如果您手动管理架构，请确保相应的列存在于正确的表中。然后，JPA 将使用此字段来检查冲突更新并在存在冲突时回滚事务。

更新：关于悲观锁定的更多信息：https://blogs.oracle.com/carolmcdonald/entry/jpa_2_0_concurrency_and 简而言之，您可以配置 JPA 来锁定对象，但这样做是个好主意的情况非常少见。换句话说，如果你是手动编写 JDBC 查询，你必须在每次选择的末尾写上“for update”来导致悲观锁定；默认是不锁定读取，因为这会让数据库和数据库用户哭泣。

Answer 2

你没有说你正在使用什么数据库，或者什么事务隔离级别。如果您使用符合 SQL 标准的 SERIALIZABLE 事务，您将不会看到此错误。 PostgreSQL 9.1 之前的版本，MS SQL Server 的一些配置，以及所有版本的 Oracle 在你请求的时候都不会给你真正的可序列化事务，所以在这样的环境中必须使用显式锁。大多数数据库产品默认为READ COMMITTED 事务隔离级别，因此您可能需要显式请求SERIALIZABLE 事务。

完全披露，我曾与 Dan R.K. MIT 的端口将真正的可序列化事务添加到 PostgreSQL 版本 9.1，以便 Wisconsin Courts 软件可以干净地处理这些问题。有关差异的示例，请参阅this Wiki page。