File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Transactions in MDB's Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Transactions in MDB Watch "Transactions in MDB New topic
Author

Transactions in MDB's

Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9616
    
    2

Guys,

What happens when a RunTimeException occurs in an MDB that was processing some message? What happens to the original message? Will it be put back to the Queue and if so how ? Help!


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Chaminda Amarasinghe
Ranch Hand

Joined: May 17, 2006
Posts: 402
Hi Jothi,

I think your question is incomplete, BUT IM NOT 100 % SURE. you should specify Runtime Ex is a App Ex or Sys Ex, and Tr argument of MDB


Thanks,
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
Hi,
What happens to the original message? Will it be put back to the Queue and if so how ?
Usually the runtime exception will lead to a rollback. What then happens to your message depends on the transaction type: In CMT the message will be put back into the queue and will be processed again (probably throwing the same runtime exception again, and so on); in BMT your message is deleted from the queue and can't be recovered.


SCJP 5 (98%) - SCBCD 5 (98%)
Chaminda Amarasinghe
Ranch Hand

Joined: May 17, 2006
Posts: 402
Originally posted by Ralph Jaus:
[QB]Hi,
Usually the runtime exception will lead to a rollback.


I can't agree on that.. All Runtime Exceptions are not System Exceptions,

Only System Exceptions lead to rollback
Tomaszz Lewandowski
Ranch Hand

Joined: Sep 07, 2007
Posts: 30
I also disagree with the statement:

... in BMT your message is deleted from the queue and can't be recovered. ...

Core spec, section 5.4.17 says:

If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowledge the message

so I think that in this case the message will not be deleted from queue.


Regards<br />Tomasz Lewandowski<br />SCJP5 (97%) | SCWCD5 (98%)
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
I can't agree on that.. All Runtime Exceptions are not System Exceptions,
By "usually" I meant those runtime exceptions that are not application exceptions. But of course you're right: It's always better to use the terms "application exception" and "system exception".
so I think that in this case the message will not be deleted from queue
The core spec, 5.4.12 says:
When a message-driven bean using bean-managed transaction demarcation uses the javax.transaction.UserTransaction interface to demarcate transactions, the message receipt that causes the bean to be invoked is not part of the transaction. If the message receipt is to be part of the transaction, container-managed demarcation with the REQUIRED transaction attribute must be used.
Note: Queuing systems work in a transactional way. So if in BMT the physical removal of the message from the queue would depend on the result of the user transaction you would need an outer transaction handling the queue and spanning the inner user transaction. But there is no requirement for nested transactions in ejb.

By the way, using a simple message consumer you can easily check that in the questionable BMT scenario there is no message in the queue after a system exception occured in the MDB.

Regards
Ralph
---------------------------------
SCJP 5.0 (98%)
[ November 02, 2008: Message edited by: Ralph Jaus ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Transactions in MDB's