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 ]
Hi, You have a point, also why not NEVER be also considered in your list?
SCJP 1.5, SCWCD 1.4, SCBCD 5
Joined: Jun 26, 2007
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
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...
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.
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 188.8.131.52 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.