• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

MDB Enthuware Question

 
Ranch Hand
Posts: 1277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The developer of an MDB wants to ensure that a message is redelivered if the onMessage method of the bean throws RuntimeException, then he should use CMT with transaction attribute REQUIRED.

Please explain
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If using CMT, MDB can only have REQUIRED and NOT_SUPPORTED. The message can only be redelivered when there is a transaction and the transaction has been rolled back. RuntimeException can cause a transaction to be rolled back. So we need to ensure there is a transaction. If using NOT_SUPPORT, there won't be a transaction. So we can only use REQUIRED.

If using BMT, see the ejbcore spec 5.4.12:

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.


So the transaction rollback won't cause the message to be redelivered.
 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see no evidence that the statement

The developer of an MDB wants to ensure that a message is redelivered if the onMessage method of the bean throws RuntimeException, then he should use CMT with transaction attribute REQUIRED.


is correct. Also the argument based on core spec 5.4.12 from Jun Liu doesn't seem to be really convincing to me. For, core spec 5.4.17 says

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


According to core spec 5.4.14 a JMS-MDB with BMT can use the acknowledge mode AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE and according to JMS 1.1 spec 4.5.2:

The result of a listener [that's the MDB in our context, remark by me] throwing a RuntimeException depends on the session's acknowledge mode.
AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message will be immediately redelivered. The number of times a JMS provider will redeliver the same message before giving up is provider dependent.


In my words: If the onMessage method of a MDB with BMT throws a RuntimeException, then the container doesn't acknowlege the method. And because of a missing acknowlegement the JMS provider redelivers the message.

Therefore I see no need to use CMT in order to ensure message redelivery due to a RuntimeException.

The situation changes if one has the stronger requirement that message redelivery should be ensured if a transaction rollback occurs: Then one has to use CMT as explained by Jun Liu above.

 
Niranjan Deshpande
Ranch Hand
Posts: 1277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That was a question from enthuware!

Perhaps the simulator wanted to ask a question like Q 12 of the sun's proficiency test posted here. This says -

If a CMT MDB's onMessage message method roll backs the transaction, then the message is redelivered. Ans as Promod pointed out in his test code, the message is redelivered 6 times on JBoss4.x

Is Enthuware trying to ask something similar but it mixed up the BMT MDB on mMessage RunTimeException with a CMT MDB onMessage transaction rollback?



 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ralph said

The situation changes if one has the stronger requirement that message redelivery should be ensured if a transaction rollback occurs: Then one has to use CMT as explained by Jun Liu above.



This is getting really confusing . When using BMT and there is a SystemException, the message is redelivered multiple times. When there is a SystemException for a BMT MDB one of the actions that the container does is to rollback the transaction. Does this mean that message redelivery is also guaranteed even using BMT when a transaction rollback occurs. Can someone clarify
 
Ralph Jaus
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Does this mean that message redelivery is also guaranteed even using BMT when a transaction rollback occurs.

It depends on how the rollback encounters: If the transaction is rollbacked because of a RuntimeException then the message is redelivered as explained above. If the rollback is caused by userTransaction.setRollbackOnly() or userTransaction.rollback() then the message isn't redelivered.

Hope this helps.
 
Promod kumar
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ralph, Thanks for the response, that helps a lot. I tried it in Jboss 4.2.2 and I was able to test both cases, message was not redelivered when setRollbackOnly() was used.
 
Who among you feels worthy enough to be my best friend? Test 1 is to read this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic