DefaultMessageListenerContainer with AqJmsFactoryBeanFactory ends up calling commit twice [DATAJDBC-94]

[spring-projects-issues]

Guillaume Polet opened DATAJDBC-94 and commented

Using a DefaultMessageListenerContainer with the attribute sessionTransacted set to 'true' and using a transactionManager ends up calling twice the method 'commi'. Once via the Transactional annotation support and a second time via org.springframework.jms.connection.ConnectionFactoryUtils.JmsResourceSynchronization.JmsResourceSynchronization which is registered as a TransactionSynchronization.

This synchronization is registered in the method org.springframework.jms.connection.ConnectionFactoryUtils.doGetTransactionalSession, and it implements the method afterCommit which eventually tries to invoke javax.jms.Session.commit().

Since the Session was created on top of the same connection as the one used by the TransactionManager, the TransactionManager will first perform its own commit on the connection and then the afterCommit of the TransactionSynchronization will itself also invoke commit on the JMS Session which delegates it eventually to underlying connection (but which is the same as the one used by the TransactionManager). This second is pointless and can even be quite dangerous because the underlying connection could be already released and re-used by another thread.

Background info where the issue happened:

• Using EclipseLink (and JPATransactionManager)
• Oracle JDBC driver v7
• Orale advanced queuing (with org.springframework.data.jdbc.config.oracle.AqJmsFactoryBeanFactory)

The way I spotted this is that, Oracle JDBC driver v7 enforces the fact that you cannot call "commit" on a connection with autoCommit = true. EclipseLink automatically set the autoCommit flag back to true whenever committing a transaction. Therefore JPATransactionManager was calling commit and setting back the autoCommit flag to true, and then the second commit was always triggering an Exception in Oracle driver

---

No further details from DATAJDBC-94

[spring-projects-issues]

Juergen Hoeller commented

I've moved this issue to the Spring Data JDBC project since the problem seems rather specific to Oracle AQ and Spring Data's AqJmsFactoryBeanFactory.

From a general DefaultMessageListenerContainer perspective, there has to be a separate commit at the JMS level since it assumes an independent resource. For a pseudo-JMS resource sharing the same underlying JDBC Connection as intended by AqJmsFactoryBeanFactory, the connection proxy should suppress the inner @Transactional-initiated commit and only let the outer JMS-initiated commit call through (or a similar solution along those lines)

[spring-projects-issues]

Thomas Risberg commented

Moving to track this on GitHub: spring-attic/spring-data-jdbc-ext#30

[spring-projects-issues]

wmadev commented

Guillaume Polet

I'm running against the same issue.

The only workaround if found so far is avoiding the check in the ojdbc7 driver by using a JVM setting.

(-Doracle.jdbc.autoCommitSpecCompliant=false)

How did you work around the issue?