views:

1720

answers:

1

I'm using Oracle 11g for my database and its Oracle Streams AQ feature as JMS implementation.

For all I know, it should be possible to implement a Spring based message-driven POJO (MDP) that uses the same data source for both transactional data access and JMS transactions -- all without XA-Transactions (IIRC, this was marketed as a feature of SpringSource Advanced Pack for Oracle).

Is this possible using Hibernate as well? Ideally, my MDP would start a JMS transaction and read a message from a queue, then re-use the transaction for data access through Hibernate. If anything goes wrong, the JMS and database transaction would both be rolled back, without using 2-phase commit (2PC).

I'm not much of a transaction guru, so before I start digging deeper, can anyone confirm that this is possible and makes sense as well?

Update:
What I want is an implementation of the Shared Transaction Resource pattern. The sample code demonstrates it for ActiveMQ and JDBC, but I need to use Oracle Streams AQ and Hibernate.

+2  A: 

2PC shouldn't be necessary, as you say, since the appserver should take care of it. However, you'll pretty much have to use JTA (i.e. JavaEE container) transactions, rather than vanilla DataSource transactions, since JMS only works with JTA.

This isn't a big deal, it's just a bit more fiddly:

  1. Your Spring config should use <jee:jndi-lookup/> to get a reference to your container's DataSource, and you inject that data source into your spring-managed hibernate SessionFactory.
  2. You then need to introduce a transaction manager into the context (<tx:jta-transaction-manager/> should work in most app-servers).
  3. In your Spring JMS MessageListenerContainer, plug the above transaction manager reference into it.

Does that all make sense, or should I elaborate? This setup should ensure that the container-managed transactions are held across JMS and Hibernate interactions.

skaffman
+1. I wonder, however, about "all without XA-Transactions (IIRC, this was marketed as a feature of SpringSource Advanced Pack for Oracle)" statement. I'm quite positive that any transaction spanning across multiple nodes (e.g. JMS and DA) has to be XA transaction and has to use 2PC - while that is usually done by container behind the scene, it's done nevertheless. Am I wrong? Is there some new amazing technology that somehow makes that unnecessary?
ChssPly76
Thanks for your comments. I updated my question after digging a little deeper.As described in the article I linked to, I'd like to avoid JTA and XA altogether. The docs for [SpringSource Advanced Pack for Oracle](https://www.springsource.com/products/enterprise/oraclepack) (download [here](http://www.springsource.com/downloads/springsource-advanced-pack-for-oracle-database-download)) also mention that passibility (see the last paragraph of chapter 3.2, which is too long to quote here, unfortunately).
sapporo
There's no way you're going to get tx coordination across datasources and JMS without JTA.
skaffman
Ah, so Oracle's AQ is just a JMS interface implementaion backed by database. Then yes, you should be able to do this without JTA because it's ultimately the same datasource. There's a sample configuration in the chapter 3.2 you've mentioned, you just need to add a sessionFactory to it and point it to the same dataSource. skaffman's answer still very much applies sans already configured MessageListener.
ChssPly76
skaffman, do you think the article is flawed? If so, can you elaborate?ChssPly76, the sample config for Advanced Pack for Oracle looks simple (will it work with HibernateTransactionManager instead of DataSourceTransactionManager?), but then I don't understand why the sample code for the article provides a JmsTransactionAwareDataSourceProxy..
sapporo