Message-Driven Bean TransactionAttribute

[Benoît de Chateauvieux]

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 ]

[Sundaram Karthick]

Hi,
You have a point, also why not NEVER be also considered in your list?

Thanks

[Sundaram Karthick]

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]

omg, i have the same problem. Is there any answer?

[Romeo Son]

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]

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.

[Mihai Radulescu]

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