讓我們考慮以下上下文：2 個 spring 集成通道，它們分別位于單獨的數(shù)據(jù)庫事務(wù)中。在第一個事務(wù)結(jié)束時，一條消息被放入第二個通道。在第一個通道中，在數(shù)據(jù)庫中創(chuàng)建元素，這些元素稍后被從第一個通道發(fā)送到第二個通道的相應(yīng)消息使用。為了確保通道 1 的事務(wù)在觸發(fā)第二個通道之前完全提交，我們的子類JpaTransactionManager在TransactionSynchronization它prepareForCommit從JpaTransactionManager流程（通道 1）如下所示：做所有的消息處理和數(shù)據(jù)庫處理流程的最后一步注冊 a在階段TransactionSynchronization中執(zhí)行 a以將消息發(fā)送到通道 2MessageChannel.sendafterCommit我的理解是，在將消息發(fā)送到第二個通道（in afterCommit）時，通道 1 的數(shù)據(jù)庫事務(wù)中所做的所有更改都被刷新并提交?，F(xiàn)在第二個通道做了一些工作（如 MQ PUT），然后更新在第一個流中創(chuàng)建的條目。我們現(xiàn)在觀察到存儲庫方法在數(shù)據(jù)庫中沒有返回任何條目，但稍后它在表中可見。然而，在第一個通道的事務(wù)中也創(chuàng)建的其他條目是可見的。這種情況每隔幾千條消息才會發(fā)生一次，通常它們在那里，但有時它們在通道 1 提交事務(wù)幾毫秒后對第二個通道不可見。我創(chuàng)建了一個應(yīng)該說明它的圖像：這Chain 1是第一個由多個ServiceActivators執(zhí)行數(shù)據(jù)庫工作的鏈組成的鏈，一個生成更多消息的拆分器，然后是另一個ServiceActivator我命名的鏈，SENDER它注冊了TransactionSynchronization（所以我的理解）應(yīng)該在紅色事務(wù)之后將例如 3 個生成的消息發(fā)送到鏈 2已完全提交，因此在藍色事務(wù)開始之前。我注意到的一件事是，有時存在但有時不存在的條目都在（不是故意）使用的一種方法中，javax.transaction.Transactional而不是org.springframework.transaction.annotation.Transactional. 但是，我們使用的是spring core 5.0.8.RELEASE，在其他問題中，我已經(jīng)看到自spring 4.2.x以來這應(yīng)該產(chǎn)生0差異。