• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Question on MDB

 
Ranch Hand
Posts: 1277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java Beat mock answer says 'valid transactional that can be applied to a MDB listener are 'required' and 'not_supported'?

? Please clarify!
 
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes it is. only REQUIRED and NOT_SUPPORTED transaction attribute types can be used for Message Driven Beans, when CMT used. Because there are no transaction propagated from the client to the MDB.
 
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
Need some more explanation...
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MDB registered with destination & whenever message is recived, MDB's onMessage method is processed
So, there is no direct client for MDB.

Supports - support previously intiated transaction,
Never - will not support previously intiated transaction
Requires_New - stops previously transaction & intiate new transaction
Mandatory - Must have previous initiated transaction

by previous transaction I mean transaction started in method before calling onMessage method

With MDB, call to onMessage is always the starting request and when there can not be previouly intiated transaction then supporting these transaction attributes do not make sense.

REQUIRED - If the client is running within a transaction and invokes the enterprise bean's method, the method executes within the client's transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.
if REQUIRED is used new transaction can be started.

NOT_SUPPORTED - If the client is running within a transaction and invokes the enterprise bean's method, the container suspends the client's transaction before invoking the method
if NOT_SUPPORTED is used, there won't be any activity realted to transaction.
 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Niranjan Deshpande wrote:Need some more explanation...



Well, think about session beans. When client invokes a method in a session beans, a transaction is propagated to the session bean from the client. So when CMT used, we can use transaction attributes to specify that how to handle that client transaction, in the bean method.

Now in MDB, we say there are 'no clients' for MDB. Bean methods are listeners, and they listen to the messages. Client may send messages to the message queue, and MDB listen to the messages from the queue. Therefore there are no direct clients for message driven beans. Hence, no transaction is propagated from anywhere to the MDB. As far as many of those transaction attributes says about how to handle the 'client transaction', all of them are meaningless here. Only thing what we can do on the MDB method is, either invoking the method with a transaction or, without a transaction, and that's only. So, REQUIRED type here can be used to create a new transaction (always) and invoke the method with that transaction. The opposite type, NOT_SUPPORTED here can used to invoke the method without any transaction.

All of the other attribute types are meaningless here. Hope this helps.
 
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
These explanations sound good-

@Deepika- thanks for emphasis on previously!
@Clark - thanks for '...what can be done is with(REQUIRED) or without(NOT_SUPPORTED) a transaction.

But this is what the In Action book has to say -

By default, the container will start a transaction before the onMessage method is invoked and will commit the transaction when the method returns, unless the transaction was marked as rollback through the message-driven context.



How does this fit in your explanations? Doesn't this contrast with Deepika's previously thing?
 
Treimin Clark
Ranch Hand
Posts: 757
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It says "By Default"

By default, the container will start a transaction before the onMessage method is invoked and will commit the transaction when the method returns, unless the transaction was marked as rollback through the message-driven context.



The default attribute type is REQUIRED always. So it creates a new transaction to invoke the onMessage() method.
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Niranjan Deshpande wrote:
Doesn't this contrast with Deepika's previously thing?


Previously means a previous method call.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think what is not clear is what it means when previously is used.
For example, SessionBean1 (which creates a transaction) is calling another SessionBean2 method(which also uses transaction). Here previously means [for SessionBean2] is SessionBean1's transaction. If REQUIRED is used in SessionBean2, SessionBean2 joins to the transaction of SessionBean1's transaction. (Any rollback from SessionBean2 will rollback SessionBean1's transaction because they are same.)
In our case since MDB cannot be called from another bean there is no previous transaction, so most of the attributes become invalid.
 
Without deviation from the norm, progress is not possible - Zappa. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic