hibernate.connection.handling_模式并需要新事务（hibernate 5.2+；Spring 4.3）_Spring_Hibernate_Jpa_Jta_Hibernate 5.x

hibernate.connection.handling_模式并需要新事务（hibernate 5.2+；Spring 4.3）

spring hibernate jpa

hibernate.connection.handling_模式并需要新事务（hibernate 5.2+；Spring 4.3）,spring,hibernate,jpa,jta,hibernate-5.x,Spring,Hibernate,Jpa,Jta,Hibernate 5.x,当我设置hibernate.connection.handling_模式和未设置模式时，我注意到JPA/JTA应用程序中的行为非常不同。我定义了以下实体： @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL) @Entity public class Notification { @Id @GeneratedValue() private long id; @OneToMany(mappedBy = "n

当我设置hibernate.connection.handling_模式和未设置模式时，我注意到JPA/JTA应用程序中的行为非常不同。我定义了以下实体：

@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)
@Entity
public class Notification {

    @Id
    @GeneratedValue()
    private long id;

    @OneToMany(mappedBy = "notification", cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Set<ErrorDetails> errorDetails;

    ....
}

我有多个通知实体保存在一个线程中，但都保存在它们自己的事务中（由Spring TxManager管理，PropagationLevel设置为REQUIRES_NEW）。我创建了一个自定义的Hibernate SessionEventListener来记录会话活动。我注意到当我有 连接。未设置处理\u模式，则所有我的实体都会提交并刷新，不会出现问题-

2018-09-24 22:33:29,740 INFO [default task-56]-[SessionEventListener] partialFlushStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] dirtyCalculationStart 0;0;com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] jdbcConnectionAcquisitionStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] jdbcConnectionAcquisitionEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,741 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,742 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,742 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] flushStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] dirtyCalculationStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,743 INFO [default task-56]-[SessionEventListener] dirtyCalculationEnd false com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,744 INFO [default task-56]-[SessionEventListener] partialFlushStart 1;0;com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,744 INFO [default task-56]-[SessionEventListener] Tx completed truefor entity com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,744 INFO [default task-56]-[SessionEventListener] END com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,744 INFO [default task-56]-[SessionEventListener] jdbcConnectionReleaseStart com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,744 INFO [default task-56]-[SessionEventListener] jdbcConnectionReleaseEnd com.myorg.model.Notification@7efedb5d 2018-09-24 22:33:29,761 INFO [default task-56]-[SessionEventListener] partialFlushStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,761 INFO [default task-56]-[SessionEventListener] dirtyCalculationStart 0;0;com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,761 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,761 INFO [default task-56]-[SessionEventListener] jdbcConnectionAcquisitionStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,761 INFO [default task-56]-[SessionEventListener] jdbcConnectionAcquisitionEnd com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,762 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] flushStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] dirtyCalculationStart com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] dirtyCalculationEnd false com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] partialFlushStart 1;0;com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] Tx completed truefor entity com.myorg.model.Notification@68c6c90d 2018-09-24 22:33:29,763 INFO [default task-56]-[SessionEventListener] END com.myorg.model.Notification@68c6c90d
但是，当我将connection.handling_mode设置为延迟的_ACQUISITION_和延迟的_RELEASE_AFTER_语句时，会话挂起在jdbcExecuteStatementStart中，事务在5分钟后超时，然后继续提交-注意jdbcExecuteStatementStart在23:28:32开始，在23:33:32结束，这是在父事务超时之后-

2018-09-24 23:28:32,506 INFO [default task-64]-[SessionEventListener] partialFlushStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,506 INFO [default task-64]-[SessionEventListener] dirtyCalculationStart 0;0;com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,506 INFO [default task-64]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,506 INFO [default task-64]-[SessionEventListener] jdbcConnectionAcquisitionStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,507 INFO [default task-64]-[SessionEventListener] jdbcConnectionAcquisitionEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,507 INFO [default task-64]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,507 INFO [default task-64]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcConnectionReleaseStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcConnectionReleaseEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcPrepareStatementStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcConnectionAcquisitionStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcConnectionAcquisitionEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcPrepareStatementEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:28:32,508 INFO [default task-64]-[SessionEventListener] jdbcExecuteStatementStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,494 INFO [default task-64]-[SessionEventListener] jdbcExecuteStatementEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,495 INFO [default task-64]-[SessionEventListener] jdbcConnectionReleaseStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,495 INFO [default task-64]-[SessionEventListener] jdbcConnectionReleaseEnd com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,495 INFO [default task-64]-[SessionEventListener] flushStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,536 INFO [default task-64]-[SessionEventListener] dirtyCalculationStart com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,536 INFO [default task-64]-[SessionEventListener] dirtyCalculationEnd false com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,536 INFO [default task-64]-[SessionEventListener] partialFlushStart 1;0;com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,538 INFO [default task-64]-[SessionEventListener] Tx completed truefor entity com.myorg.model.Notification@482bb8c8 2018-09-24 23:33:32,538 INFO [default task-64]-[SessionEventListener] END com.myorg.model.Notification@482bb8c8
作为记录，我已经从Hibernate4.x迁移了我的应用程序，在Hibernate4.x中我们没有遇到过这样的问题。总的来说，我注意到Hibernate 5.2对于需要挂起父事务的嵌套事务的行为似乎非常奇怪。我几乎被难住了：/
更新
我决定在线程挂起时进行线程转储，并且我注意到实际上该语句已提交给MariaDB执行，事实上ShowProcessList列出了挂起的update语句。Java等待语句执行完成时的线程堆栈-

java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) - locked <0x0000000699da2af0> (a java.io.BufferedInputStream) at org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully(ReadUtil.java:82) at org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully(ReadUtil.java:92) at org.mariadb.jdbc.internal.common.packet.RawPacket.nextPacket(RawPacket.java:77) at org.mariadb.jdbc.internal.common.packet.SyncPacketFetcher.getRawPacket(SyncPacketFetcher.java:67) at org.mariadb.jdbc.internal.mysql.MySQLProtocol.getResult(MySQLProtocol.java:957) at org.mariadb.jdbc.internal.mysql.MySQLProtocol.executeQuery(MySQLProtocol.java:1066) at org.mariadb.jdbc.internal.mysql.MySQLProtocol.executeQuery(MySQLProtocol.java:1046) at org.mariadb.jdbc.MySQLStatement.execute(MySQLStatement.java:289) - locked <0x0000000699da2b18> (a org.mariadb.jdbc.internal.mysql.MySQLProtocol) at org.mariadb.jdbc.MySQLStatement.executeUpdate(MySQLStatement.java:364) at org.mariadb.jdbc.MySQLPreparedStatement.executeUpdate(MySQLPreparedStatement.java:148) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) at org.hibernate.dialect.identity.GetGeneratedKeysDelegate.executeAndExtract(GetGeneratedKeysDelegate.java:57)

java.lang.Thread.State:可运行位于java.net.SocketInputStream.socketRead0（本机方法）位于java.net.SocketInputStream.socketRead（SocketInputStream.java:116）位于java.net.SocketInputStream.read（SocketInputStream.java:171）位于java.net.SocketInputStream.read（SocketInputStream.java:141）在java.io.BufferedInputStream.fill处（BufferedInputStream.java:246）位于java.io.BufferedInputStream.read1（BufferedInputStream.java:286）在java.io.BufferedInputStream.read处（BufferedInputStream.java:345） -锁定（java.io.BufferedInputStream）位于org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully（ReadUtil.java:82）位于org.mariadb.jdbc.internal.common.packet.buffer.ReadUtil.readFully（ReadUtil.java:92）位于org.mariadb.jdbc.internal.common.packet.RawPacket.nextPacket（RawPacket.java:77）位于org.mariadb.jdbc.internal.common.packet.SyncPacketFetcher.getRawPacket（SyncPacketFetcher.java:67）位于org.mariadb.jdbc.internal.mysql.MySQLProtocol.getResult（MySQLProtocol.java:957）位于org.mariadb.jdbc.internal.mysql.MySQLProtocol.executeQuery（MySQLProtocol.java:1066）位于org.mariadb.jdbc.internal.mysql.MySQLProtocol.executeQuery（MySQLProtocol.java:1046）位于org.mariadb.jdbc.MySQLStatement.execute（MySQLStatement.java:289） -锁定（一个org.mariadb.jdbc.internal.mysql.MySQLProtocol）位于org.mariadb.jdbc.MySQLStatement.executeUpdate（MySQLStatement.java:364）位于org.mariadb.jdbc.MySQLPreparedStatement.executeUpdate（MySQLPreparedStatement.java:148）位于org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate（WrappedPreparedStatement.java:537）位于org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate（ResultSetReturnImpl.java:175）位于org.hibernate.dialogue.identity.GetGeneratedKeysDelegate.executeAndExtract（GetGeneratedKeysDelegate.java:57）
终于解决了！由于相关表的更新，这是一个死锁。表中显示了以下关系：-

Notification *<-->* Sources

事务2735810在Sources`表上保留行锁，因为它已在父事务中“保存”

事务2735824现在正在等待此锁。原因是通知表中的一列定义了源
表
的外键。因此，显然，由于行已被锁定，子事务已进入死锁状态

弗拉德的博客解释了这一点-
这里需要注意的是，通知实体没有定义与Sources实体的Hibernate关系，约束只存在于MySQL数据库中
因此，我决定在子事务完成后更新父源的实体，以避免锁定父表

我想知道如果关系已经确定，Hibernate会以不同的方式对待它。
你已经问过Vlad，他告诉你下一步要做什么。所以只有Hibernate的人才能真正帮助你。是的，他问过Vlad，但他怀疑是Spring引起了问题。有什么想法吗？为什么需要在声明之后延迟获取和发布？因为我不想在整个交易结束之前保持连接。顺便说一句，我做了进一步的调试，注意到insert查询在发送到MariaDB（即org.hibernate.dialogue.identity.GetGeneratedKeysDelegate.executeAndExtract（PreparedStatement insert，SharedSessionCompactImplementor会话）中的第一行）后就被阻塞了。我怀疑是表锁，但在执行此查询时，这是唯一一个在表上持有写锁的连接。
Notification *<-->* Sources

---TRANSACTION 2735824, ACTIVE 104 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 5 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1 MySQL thread id 59, OS thread handle 0x7f72d8fb4b00, query id 47941 localhost 127.0.0.1 adminuser update insert into Notification (id, sourceId, message) values (NULL, 17, 'MISSING') Trx #rec lock waits 1 #table lock waits 0 Trx total rec lock wait time 0 SEC Trx total table lock wait time 0 SEC ------- TRX HAS BEEN WAITING 104 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2726 page no 3 n bits 104 index `PRIMARY` of table `sample`.`Sources` trx table locks 3 total table locks 2 trx id 2735824 lock mode S locks rec but not gap waiting lock hold time 104 wait time before grant 0 ------------------ ---TRANSACTION 2735810, ACTIVE 104 sec 5 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 2 MySQL thread id 60, OS thread handle 0x7f72d83feb00, query id 47927 localhost 127.0.0.1 adminuser cleaning up Trx #rec lock waits 0 #table lock waits 0 Trx total rec lock wait time 0 SEC Trx total table lock wait time 0 SEC