DMLC with cacheLevel=CACHE_CONNECTION and a non-JMS transaction manager causes the shared connection to be closed after the first transaction [SPR-5127]

[spring-projects-issues]

Joe Kearney opened SPR-5127 and commented

When the DMLC is used with a non-JMS transaction manager (for example DataSourceTransactionManager) then DMLC#doReceiveAndExecute() delegates to ConnectionFactoryUtils which binds the shared connection to the transaction and registers a synchronization to close it upon transaction completion. When the first transaction completes this synchronization runs and the shared connection is closed (there is no proxy or smart connection pattern used as in JDBC). Subsequent use of the now closed connection fail with IllegalStateException (as per JMS spec).

The bug appears to be in the ResourceFactory passed from DMLC to CFUtils. This implements createConnection() by returning a reference to the shared connection, however CFUtils is expecting a fresh connection that is can close (or at least one that suppresses close).

Using higher levels of caching avoids this issue since the DMLC never calls into CFUtils, it just uses the pre-established shared session.

We also notice that using a JmsTransactionManager causes the shared connection to be ignored, since a new connection is created and bound for each transaction.

---

Affects: 2.5.4

[spring-projects-issues]

Juergen Hoeller commented

Thanks for raising this! I've revised DMLC to correctly work with a non-JMS transaction manager and CACHE_CONNECTION level, not prematurely closing the shared Connection in that case. We simply expose a shared Connection proxy to the transaction synchronization code now, rather than the raw shared Connection.

This will be available in tonight's 2.5.6 snapshot (http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR). Please give it a try and let us know whether it works for you...

Juergen

[spring-projects-issues]

Joe Kearney commented

Passes our test case using a non-JMS transaction manager, looks good. Still fails with a JMSTxMan since a new connection is created eagerly each transaction, but I suppose this is to be expected.

Thanks for such a quick turnaround on this, Juergen.

Joe