File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Message-Driven Bean TransactionAttribute 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 "Message-Driven Bean TransactionAttribute" Watch "Message-Driven Bean TransactionAttribute" New topic

Message-Driven Bean TransactionAttribute

Benoît de Chateauvieux
Ranch Hand

Joined: Aug 10, 2007
Posts: 183
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:
and for me, it's the same configuration: no client.

Your opinion ?

[ October 29, 2007: Message edited by: Beno�t de CHATEAUVIEUX ]

SCJP5 | SCBCD5 | SCEA5 Part 1
Sundaram Karthick

Joined: Jun 26, 2007
Posts: 24
You have a point, also why not NEVER be also considered in your list?


SCJP 1.5, SCWCD 1.4, SCBCD 5
Sundaram Karthick

Joined: Jun 26, 2007
Posts: 24
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
Cainiao Zou
Ranch Hand

Joined: Mar 03, 2009
Posts: 36
omg, i have the same problem. Is there any answer?
Romeo Son
Ranch Hand

Joined: Mar 12, 2007
Posts: 92

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...

Roberto Perillo

Joined: Dec 28, 2007
Posts: 2271

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.

Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918


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 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,

    I agree. Here's the link:
    subject: Message-Driven Bean TransactionAttribute
    It's not a secret anymore!