aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Transaction in MDB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Transaction in MDB" Watch "Transaction in MDB" New topic
Author

Transaction in MDB

Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
Hi,
I have certain questions on MDB regarding
1) what will happen to the transaction when following things happen.

a) A BMT Message Bean throws a system exception

b) A BMT Message Bean sets the transaction for rollback

c) A CMT Message Bean with Not Supported throws a system exception

d) A CMT Mesaage Bean with Required throws a system exception

e) A CMT Mesaage Bean with Required sets transaction for rollback

And while we are at it ...
2) what will happen in each of these cases to
a) the message bean instances (discarded or kept alive ) and
b) messages (resent or not)...

Sorry for the long question. :-)
Giju George
Ranch Hand

Joined: Jun 08, 2004
Posts: 333
For ques a,c and d, refer spec : 18.3.2 Exceptions from message-driven bean methods


SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCEA
Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62
I have certain questions on MDB regarding
1) what will happen to the transaction when following things happen.
b) A BMT Message Bean sets the transaction for rollback


Spec, 15.5.1

Invoking the getRollbackOnly and setRollbackOnly methods is disallowed in the
message-driven bean methods for which the Container does not have a meaningful transaction
context, and for all message-driven beans with bean-managed transaction demarcation.


==> IllegalStateException



e) A CMT Mesaage Bean with Required sets transaction for rollback


spec 17.6.3.2: If the onMessage method does not successfully complete or the transaction is rolled back by the Container, JMS message redelivery semantics apply.

=> the message will be redelivered and all in the transaction involved ressources will be rolled back.
[ August 11, 2004: Message edited by: Severin St�ckli ]
Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
First of all thanks for the good responses. I went through the specs locations pointed, and they were really clear and helpful. Still one thing remains unclear to me. What would happen to the message if we get a system exception. I meant it is clearly given that in both the cases of BMT and CMT...the transaction if present will be rolled back..and message bean discarded and logging will be done. But would the message be resent?

Also from Specs 15.5.1 ... you have mentioned that we cannot call setRollbaclOnly() on a BMT. I think that at that point the specs was talking about the setRollBackOnly() method of the MessageDrivenContext. In case of a BMT bean we cannot call this method ..but we have a similar method available in the class UserTransaction which we can call. I'm not absolutely sure but I think we can call that method.
Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
Another thing which came to my mind. In the specs 17.6.3.2 It is written that -> "The Container attempts to commit the transaction when the onMessage method has completed. If the onMessage method does not successfully complete or the transaction is rolled back by the Container, JMS message redelivery semantics apply."
The key word here to watch I think is "rolled back by the Container" So my question is that in my above query would catagory e) come under this. Because when we call setRollBackOnly() on a CMT MDB then it is not the Container but the Bean Provider which is telling the Transaction to roll back explicitly. Again I'm not very sure. May be i'm too confused on this.
Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62
I think that at that point the specs was talking about the setRollBackOnly() method of the MessageDrivenContext.


Yes, you're absolutely right, I didn't see that. In this case, you can call this method and, as far as I understood, the transaction will rollback although you call "commit". In this case, the same as for your question (e) will occurre

So my question is that in my above query would catagory e) come under this


If I understood you right, you'r question is if the behaviour is the same for "user-rollbacks" and "container-rollbacks". My answer would be yes.

Severin
[ August 11, 2004: Message edited by: Severin St�ckli ]
Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
Let me sum up what we have until now.

a, c and d) IF BMT/CMT MDB throws a system exception - Bean discarded, if in transaction transaction rolled back and message looged.

b and e) IF BMT/CMT MBD calls setRollBackOnly() - transaction rolled back and message redelivered

One question remains is what will happen to the message in cases a,c,d. Would it be redelivered?
Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
I just found out that in case of a BMT MDB if we call the method setRollBackOnly() the message is not redelivered( unlike the same case with CMT ) as the acknowledgement in case of BMTs is tied to the successfull completion of the method. So it is quite possible that if we see something wrong in the message ( like a poison message) we call this method on a BMT MDB. That way the message will not come back to haunt us again.
Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62
... case of a BMT MDB if we call the method setRollBackOnly() the message is not redelivered( unlike the same case with CMT )


Yes, you're absolutely right. Now I can't remember what I'm was thinking this morning (perhaps it was too early ). In the case of BMT MDB, the Message that calls's the MDB CAN'T be part of the transaction, since the Bean Provider will start the transaction later. Therefore, the message CAN'T be redelivered because the transaction fails.

However, the container will acknowledge the message according to the "JMS-Acknowledge semantic" (Spec 15.4.8)that means:

- No message redelivery for successful onMessage call
- Message redelivery in exception case (=> answer to your question a)

See also Using the JMS API in a J2EE(TM) Application:

If a message-driven bean uses bean-managed transactions, the message receipt cannot be part of the bean-managed transaction, so the container acknowledges the message outside of the transaction. When you package a message-driven bean using the deploytool, the Message-Driven Bean Settings dialog box allows you to specify the acknowledgment mode, which can be either AUTO_ACKNOWLEDGE (the default) or DUPS_OK_ACKNOWLEDGE. If the onMessage method throws a RuntimeException, the container does not acknowledge processing the message. In that case, the JMS provider will redeliver the unacknowledged message in the future.

Hope this helps (for me too )

Severin
Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62
One question remains is what will happen to the message in cases a,c,d. Would it be redelivered?


In the above article you will find the some ansers of those questions: yes, the message will be redelivered for a and d.

For (c), this is a very good questions I didn't find in any documentation. I would guess that the message is redelivered since the container must implement a meaningful behaviour and the easiest would be to use the JMS's AUTO_ACK. But this is only a guess...

Severin
Nitin Mehhta
Ranch Hand

Joined: May 18, 2004
Posts: 48
Thanks again. I think now probably all the answers are clear. Just for someone who might read this post I'll summarize -->

a, c and d) IF BMT/CMT MDB throws a system exception - Bean discarded, if in transaction transaction rolled back and message looged. Message redelivered.

b) IF BMT MBD calls setRollBackOnly() - transaction rolled back and message not redelivered

e) IF CMT MBD calls setRollBackOnly() - transaction rolled back and message redelivered
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Transaction in MDB