MDB and Tx

[amol deshpande]

friends please tell with explaination what is correct of following

1)MDB's have no client views.They can be called by other beans
such as entity or session or mdb itself(I mean by using message, not client view).When other bean sends a message to mdb, the Tx that caller bean method has, will never get propagated to onMessage. container always starts new Tx (if its Required in case of CMT) and suspends old tx.

2) consider following code
//in session bean
// assume exceptions are handled
public void foo()
{
ut.begin();
//send mdb a message
//
st.executeQuery(sql);

ut.commit();
}

here, the mdb gets the message, but whatever it does with Tx there has no relation to Tx in foo.
Like if MDB rollbacks or calls setRollbackOnly, its not affecting Tx of foo.(coz its different Tx)

3)
what happens if a bean calls(in same tx)
1commit() after setRollbackOnly()

2rollback() after commit();

[Sun Raj]

Amol,
Thanks for the questions:
Here are my answers.

1. Most part is true, but, the old tx is not suspended.
It is only when the old Tx is committed that the message is sent to the destination.

2. Most part is true, but, the message is put on the queue/topic only after the ut.commit().

3. Not sure what exception will be received.

SR

[amol deshpande]

Hi there,
thankx for answers,
can u refer me to spec or hfejb so that I can understand than just to take it as true!!

Amol.

[Sun Raj]

Hi Amol,
I did not refer to HF or the ejb spec. I have just started preparing for the SCBCD but have gone thru Mastering EJB by Ed Roman both 2 & 3 Editions at my work.
I was refering to pg 241 & 242 of Mastering EJB Edition 3.
The following is the text:
MDBs do not run in the same tx as the producer who sends the messages, because there are typically 2 tx associated with every durable JMS message (one tx for producers to put the message on the q, and another tx for the JMS mdb to get the message off the queue). It is theoretically impoissible for the JMS mdb to participate in the same Tx as the producer, because until the producer commits the tx, the message would'nt even appear on the q.

SN

[Keerthi P]

1. Most part is true, but, the old tx is not suspended.
It is only when the old Tx is committed that the message is sent to the destination.

The old transaction, caller initiated one, will be suspended because onMessage(...) will not run in the scope of client's transaction. It either runs in a new (for CMT) or unspecified (CMT) or self initiated (BMT) transaction scope.

2. Most part is true, but, the message is put on the queue/topic only after the ut.commit().

The message reaches the MDB but if the executeQuery() should fail, the container cannot rollback the sent message. MDB has its own transaction.

3. Not sure what exception will be received.

No exception will be thrown. There won't be anything to rollback because whatever the bean had to commit has been committed already. Calling rollback() immediately after commit() is a NO-OP; it does not rollback() the committed transaction either.
[ March 12, 2005: Message edited by: Keerthi P ]

[Keerthi P]

It is theoretically impoissible for the JMS mdb to participate in the same Tx as the producer, because until the producer commits the tx, the message would'nt even appear on the q.

A BIG caution here. This quote is correct. But it talks about what the case would be if both the MDB and the message producer should run the same transaction context. The MDB wouldn't be able to consume the message unless the producer commits (if both run in same TX). This is not desirable which is why MDB gets its own transaction. It does get the message before the caller (msg producer) issues commit(). But, it wouldn't be possible to rollback or pretend as if it did not receive the message because there are 2 transactions.

[amol deshpande]

Thankx ....
I got it..!!!
An MDB will always run its own tx or unspecified but never in callers one.
If other bean sends message to mdb in a tx, the message will only be send if and when tx commits.
Amol.