• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Bear Bibeault
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • salvin francis
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
Bartenders:
  • Jj Roberts
  • Carey Brown
  • Scott Selikoff

Message-Driven Bean TransactionAttribute

 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

The specs 13.3.7 says:

For a message-driven bean�s message listener methods (or interface), only the REQUIRED and NOT_SUPPORTED TransactionAttribute values may be used.


And OReilly EJB3 explains:

Message-driven beans may declare only the NotSupported or Required transaction attribute.
The other transaction attributes don't make sense in message-driven beans because they apply to client-initiated transactions. The Supports, RequiresNew, Mandatory, and Never attributes are all relative to the transaction context of the client. For example, the Mandatory attribute requires the client to have a transaction in progress before calling the enterprise bean. This is meaningless for a message-driven bean, which is decoupled from the client.



I don't understand why RequiresNew cannot be used:
For me, RequiresNew and Required both match the goal "the bean will use transaction".
And as there is no client, the transaction will always be initiated by the container.

Additionally, an EJB Timeout callback method accepts the 3:
REQUIRED
REQUIRES_NEW
NOT_SUPPORTED
and for me, it's the same configuration: no client.

Your opinion ?
Thanks,

Beno�t
[ October 29, 2007: Message edited by: Beno�t de CHATEAUVIEUX ]
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
You have a point, also why not NEVER be also considered in your list?

Thanks
 
Sundaram Karthick
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As the container is responsible for controlling the transaction for MDB, there can be only 2 states either the bean can participate in a transaction or cannot. When it takes place in a transaction REQUIRED attribute is chosen and when bean not participating in a transaction NOT_SUPPORTED is chosen.
As client transaction propogation is not in scope, REQUIRED_NEW and NEVER is not brought into picture
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
omg, i have the same problem. Is there any answer?
 
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right, specs 13.6.3 explains that:

Only the NOT_SUPPORTED and REQUIRED transaction attributes may be used for message-driven bean message listener methods. The use of the other transaction attributes is not meaningful for message-
driven bean message listener methods because there is no pre-existing client transaction context (REQUIRES_NEW, SUPPORTS) and no client to handle exceptions (MANDATORY, NEVER).



However, the question still remains why REQUIRES_NEW is allowed for Timeout callbacks but not for message-driven bean listeners...
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
REQUIRES_NEW won't make sense because, when the onMessage method of your MDB is called by the EJB container, there will be no open transactions. Since it won't open any transactions before calling the onMessage method of your MDB, then REQUIRES_NEW is useless.
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

The most easy way to understand this is : "the MDB does not have a client like the other beans (sless and sfull)". Only container interacts with the MDB and it do it after some very simplistic rules :
  • enroll the resource in transaction - for this only REQUIRES will fit
  • don't enroll the resource in transaction - for this only NOT_SUPPORTED will fit


  • by resource I mean the JMS resource.

    NEVER will cause an exception, to avoid this the container needs to call the MDB only outside of the transaction context. This will bound the container to a certain strategy (ugly design).
    REQUIRED_NEW can not be used because (according with 13.6.3.2 of EJB 3.0 Core specification) the transaction must be started before the involved MDB action listener method is called. The REQUIRED_NEW starts the transaction after the method was call.

    The only acceptable way when you may use : REQUIRED_NEW with a MDB is if the MDB is a timed object. Timed objects can use REQUIRED, REQUIRED_NEW, NOT_SUPPORTED.


    Best Regards,
    Mihai
    reply
      Bookmark Topic Watch Topic
    • New Topic