David Fra

Greenhorn
+ Follow
since Sep 10, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by David Fra

It seems to me that an MDB either wants to run in a transaction or it doesn't. Given an MDB's disconnect from any existing transactional context, REQUIRED fulfills the former and NOT_SUPPORTED fulfills the latter. That black and white view seems reasonable, but getting to it was obscured by the distracting (and apparently irrelevant) notions of suspending transactions.
Hi Ryan,

That does seem very reasonable, and was a line of argument I was pursuing myself until I read what the Burke/Haefel EJB3 book had to say about NotSupported - the incoming transaction is suspended! So, if it can do that for NotSupported it ought to be able to do that also for RequiresNew. Even worse, for Required, if the client is part of a transaction, the MDB is automatically included in its transaction scope.

Although the MDB is totally decoupled from the message sender, the container presumably has access to the transaction context - and this is where the answer lies I suspect but i haven't managed to find out much about what actually goes on here.

So, I'm still not convinced but thanks anyway!

Cheers,
David
Apologies for talking to myself, so soon as well

From the perspective of an MDB, it either runs in a transaction or it doesn't.
Given that the MDB cannot have the caller's transaction context passed into it, the former situation implies REQUIRES_NEW and the latter situation implies NOT_SUPPORTED

?
I can't fathom the logic either. I've read the 'self-evident' paragraph in EJB 3 by Burke and Monson-Haefel many times but am none the wiser.

While I understand that the client transaction context cannot be passed to the MDB, that doesn't seem to be sufficient to allow logic to be applied to deduce that NotSupported and Required are the only options.

NotSupported makes sense given that its transaction scope is not propagated to the target EJB, in this case an MDB.
Supports requires the transaction scope, if one exists, to be propagated - so that can be ruled out.
Required doesn't make sense because if a transaction is active the target EJB executes in this scope - and surely this requires that the transaction scope be propagated?
RequiresNew would seem to be a candidate given that it creates a new transaction scoped to the MDB method, irrespective of the state of the client transaction. But this is not a candidate so my logic somewhere is wrong.
Mandatory can be ruled out on tx ctx propagation grounds.
Never - no tx ctx propagation but still need to know if the client is part of a tx to throw an exception - but isn't this done by the container? Even so, ruled out because it would only ever result in an exception being thrown.

So, NotSupported and RequiresNew seem reasonable to me, but that's wrong (unless there's a typo in the book?)