Only the Required and NotSupported transaction attributes may be used for message-driven beans. The use of the other transaction attributes is not meaningful for message-driven beans because there can be no pre-existing transaction context (RequiresNew, Supports)
What that means "...there can be no pre-existing transaction context..."? RequiresNew and Supports mean "pre-existing transaction context", and why they don't work for MDB?
[ April 19, 2004: Message edited by: Alibabra Sanjie ]
So if you want it in a transaction, you choose "Required". Although "RequiresNew" would theoretically do the same thing, it would be redundant because the difference between "Required" and "RequiresNew" occurs when there IS a transaction status before the method (and we just said that wouldn't happen). And without a transaction status beforehand, Mandatory would throw an exception, so that one makes no sense.
If you do not want your onMessage to run in a transaction, you theoretically could choose any of "Supports", "NotSupported", or "Never", but "NotSupported" is the one that best describes what you want to happen, and so was the one the designers chose. I think this choice is somewhat arbitrary but "NotSupported" is the best choice because even outside of message driven beans, "NotSupported" always runs in an unspecified transaction context no matter what the previous transaction status is (you can't say that about the other choices).
[ April 19, 2004: Message edited by: Dale Seng ]
I would also like to have a convincing answer for this.
Can some one please give answer to what Alibabra has asked??
Originally posted by Alibabra Sanjie:
I am still not convinced!
As I said, I think it's a somewhat arbitrary decision. We can only speculate about what was going through the minds of the designers....but how about this....
RequiresNew has more code (to suspend any inbound transactions). Although that code would not be active in MDB's, the classes supporting "RequiresNew" would be larger than for "Required". Too bad this argument goes against the use of "NotSupported", since it has the 'suspend' code in it as well. Dang! But "NotSupported" works for me because no matter what the inbound transaction situation is, the method always runs without a transaction (not true for "Supports"). Also "Supports" gives the wrong message (this is likely the biggest reason it wasn't selected). The whole deal is you want to tell your MDB NOT to use a transaction, then you select something called "Supports"? That would be completely whacked, and folks would have a field-day hacking on the designers for that one.