在 MySQL 休眠 JPA 事务期间未检测到死锁

Question

警告！！！TL;DR

MySQL 5.6.39  

mysql:mysql-connector-java:5.1.27

org.hibernate.common:hibernate-commons-annotations:4.0.5.Final  

org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final  

org.hibernate:hibernate-core:4.3.6.Final

org.hibernate:hibernate-entitymanager:4.3.6.Final  

org.hibernate:hibernate-validator:5.0.3.Final

HTTP 方法： POST， API 路径： /reader

实体“阅读器”引擎：innoDB

id

name

total_pages_read

类映射：

@Entity

@Table(name = "reader")

public class Reader{

    @Column(name = "id")

    private Long id;

    @Column(name = "name")

    private String name;

    @Column(name = "total_pages_read")

    private Long total_pages_read;

    

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "reader", orphanRemoval = true)

    private Set<Book_read> book_reads;

    ...

}

我使用方法 createEntity（） 并在 Reader write service 类中重新计算 TotaltalPageRead（）：

@Service

public class ReaderWritePlatformServiceJpaRepositoryImpl{

    private final ReaderRepositoryWrapper readerRepositoryWrapper;

   

    ...

    @Transactional

    public Long createEntity(final Long id, final String name, final Long total_pages_read){

        try {

            final Reader reader = new Reader(id, name, total_pages_read);

            this.readerRepositoryWrapper.saveAndFlush(reader);

            return 1l;

        } catch (final Exception e) {

            return 0l;

        }

    }

    

    ...

}

HTTP 方法： POST， API 路径： /bookread

实体“book_read”引擎：innoDB

id  

reader_id  

book_title  

number_of_pages 

类映射：

@Entity

@Table(name = "book_read")

public class Book_read{

    @Column(name = "id")

    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)

    @JoinColumn(name = "reader_id")

    private Reader reader;

    @Column(name = "book_title")

    private String book_title;

    @Column(name = "number_of_pages")

    private Long number_of_pages;

    

    ...

}

Answer 1

您遇到的更新被称为丢失更新，这真的不是JPA级的问题，您可以在MySQL shell中轻松重现此问题。我假设您没有在数据库本身中进行任何更改，因此您的默认事务隔离级别是 。REPEATABLE READ在MySQL中，不会检测到可能的丢失更新（即使这是此隔离级别的常见理解）。您可以在SO和评论线程上查看此答案以了解更多信息。REPEATABLE READ基本上，通过使用MVCC，MySQL试图避免争用和死锁。在你的情况下，你将不得不做出权衡，并选择为了一致性而牺牲一些速度。您可以选择使用语句或设置更严格的隔离级别，即（您可以对单个事务执行此操作）。这两个选项都将阻止读取，直到并发事务提交/回滚。因此，您将在稍晚一点（或更晚，具体取决于应用程序的要求）看到数据的一致视图。SELECT ... FOR UPDATESERIALIZABLE你也可以在这里，这里和这里阅读这个。并发性很难。:)更新：在考虑了下面的评论之后，您实际上还有另一种选择：为数据模型实现乐观锁定。JPA对此有支持，请看这里和这里。您实现的目标基本上是相同的，但是使用稍微不同的方法（您将不得不重新启动未能不匹配版本的事务），并且由于锁定较少，因此争用较少。

Answer 2

我认为您面临的问题是，FK 关系的属性锁定由关系的拥有方控制。由于集合是用它注释的，因此它不会控制锁，因此另一端会这样做，这意味着在更新集合时，您将获得两个单独的锁，它们实际上并不能相互识别。book_reads@OneToMany(mappedBy = "reader")删除和注释应该可以解决这个问题。Book_read.readermappedBy所有这些实际上都适用于具有版本属性的乐观锁定，这是无论如何都要执行操作的推荐方法。另请参阅Vlad Mihalcea关于该主题的文章：https://vladmihalcea.com/hibernate-collections-optimistic-locking/