MDB and transaction type attributes

[Himai Minh]

In a Message driven bean, it can only have REQUIRE or NOT_SUPPORT transaction type attributes for the business methods.

Why REQUIRE_NEW, NEVER, MANDATORY and SUPPORT should not be used?

(According to Oreilly's EJB 3.1, it says REQUIRE or Not_SUPPORT are container initiated while the others are client initiated.
In MDB, there is no client initiated transactions.)

Can anyone explain more about this ?
I don't see any reason why we cannot use REQUIRE_NEW and etc even if there is no client for MDB.

[range ke]

you never go with a transaction context on onMessage methods since it is invoked by the container.

RequireNews <-- no original transaction, meaningless
Never<---it throws exception if come with transaction. this case never happen
mandatory <--- it must throws exception if you can apply
supports < -- no original transaction

valid case:
require --> intend you need a transaction
not supported --> you don't need it

answer by myself, you may find more official answer from others

[Himai Minh]

Thanks Range Ke.

I read Head First EJB chapter 9. There is a short paragraph briefly explaining why MDB only uses REQUIRE and NOT_SUPPORT.

REQUIRE_NEW is not used because MDB is not invoked by the client and there is no pre-exisiting transaction.

In the case of REQUIRE_NEW, the client must invoke a() method in a transaction context txn A. a() method invokes b() method. If b() method requires REQUIRE_NEW, the container will create a new transaction for b() to execute. In this case, txn A is the pre-existing transaction.

But in message driven bean's onMessage method, the container only invokes this onMessage method either in a transaction or not in a transaction. There is no pre-exisiting transaction.
The same works for MANDATORY which requires a pre-existing transaction. However, in MDB, there is no pre-existing transaction.

NEVER is not used because there is never a pre-existing transaction for MDB. It seems redundant.

SUPPORT is not used because REQUIRE or NOT_SUPPORT have already covered this case, so SUPPORT is redundant.