File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes MDBs and Transactions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "MDBs and Transactions" Watch "MDBs and Transactions" New topic

MDBs and Transactions

Luke Murphy
Ranch Hand

Joined: May 12, 2010
Posts: 300
I am bit confused with how exactly MDBs work with Transactions.

For example,
suppose we have a simple standalone java message producer which sends a message to a Queue. A MDB's onMessage() picks it up.
Let's say the MDB makes some updates to the database and then invokes a method on a stateless session bean which also updates a database.

By default the transaction attribute of the MDB and stateless session bean would be REQUIRED.

If the stateless session bean database update fails, I presume the MDB's database updates also get rolled back.
But, does the message get rolled back? If not when would the message be rolled back?

Does it make any difference if the MDB is a topic or a queue? Does it make any difference if the message producer is a standalone client or
a stateless session bean with it's own transactional behaviour?

Any help appreciated.

aryan Sharma

Joined: Oct 10, 2005
Posts: 27
all DB trasactions would be rolled back and the message would be redelivered.
Poobhathy Kannan
Ranch Hand

Joined: May 26, 2004
Posts: 94
it's not clear what you mentioned by "database updates will rollback, when database update fails". I don't think that data will just be rolled back if there is a update failure unless a system exception or an ApplicationException( with rollback=true) is thrown. I assume that you use CMT as you mentioned about REQUIRED Tx attribute.

I think this post would give you a better inside
Gladwin Burboz

Joined: Feb 26, 2008
Posts: 25

It dosen't matter what the message producer is. Once the producer commits the message, it will appear on the queue.

In scenario that you described, as Aryan mentioned, all DB trasactions would be rolled back and the message would be redelivered. This is because global transaction is rolled back when database update fails and hence all the participating transactions rollback.

What you need to watch out is if everything goes fine and call to onMessage() method successfuly completed. Here you have two or more resources involved in this scenario (JMS/DB). At this point cointainer will start to commit transactions on each resource. If we have say two resources viz R1(JMS) and R2(DB), first container will commit resource R1 and then resource R2 (order is not garaunteed). Now if something goes wrong while container is performing commit on resource R2 then it will rollback, but resource R1 is already commited.

If you are using XA drivers for your transactions, only then will container take care of this scenario and gaurantee commit all or none for all the XA resource transactions that are participating containers global transaction.

For more info please read on 2-phase commit and XA transactions.

<a href="" target="_blank" rel="nofollow"></a>
I agree. Here's the link:
subject: MDBs and Transactions
It's not a secret anymore!