Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why allow Required MDB xtion attribute

 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the reason for allowing the Required transaction attribute for MDB's? And why are the Never and Supports attributes not allowed?
I agree with the NotSupported attribute for MDB's. That option makes sense.
It renders transaction-aware MDB's non-transactional but allows a transaction to harmlessly send to the MDB.
It seems inconsistent to me the allow Required but not Supports.
And it seems inconsistent to allow NotSupported but not Never.
Does anyone know the reasoning behind this?
I think it would also be useful to be able to say Never, for example, to help ensure that a certain MDB is not inadvertantly used during a transaction by another programmer in the future.

My question was inspired by Yanqu Zhou's recent question on SB Transaction Attributes. Thanks, Zhou!
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11943
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,
From the spec 17.6.3:
Only the NotSupported and Required 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) and no client to handle exceptions (Mandatory, Never).

Regards, Andrew
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew,
Thanks for the info. I see the words but it does not explain their reasoning.
The spec seems to say that one the one hand an MDB can Require transaction even there can be no pre-existing transaction context. Ok the only way
that the MDB can then run under a transaction is for its container to create one. Fine. But on the other hand then why can't we make that transaction Mandatory?
As for the NotSupported. It seems to mean that the MDB will somehow cause the Producer's transaction to be suspended (assuming there was one). I don't believe that, but for the sake of argument.... Ok If an MDB can do that, then why can't it say Never ? Something is inconsistent here.
If, on the other hand, we assume that NotSupported does NOT mean that an
existing transaction at the Producer will be suspended, then what COULD it mean? It could mean that the MDB itself could never run on ITS container under its own context. But that would be identical to the meaning of Never.
All I can say is, HELP!

The confusion might have something to do with whether they are talking about the container where the Producer runs, versus the container where the MDB runs. I think that some of the Transaction attributes refer to the first, and others to the second. I just guessing now. I would like a consistent explanation.
:roll:
 
hover cheng
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, John
I read your question, and found that there are two key factors should be well understanded:
1. The MDB is stateless, so NO transaction context could be inherited from it's previous status. This is like stateless session bean, and quite opposite to stateful session bean.
2. The onMessage method of MDB is NOT invoked by client directly, so no transaction context can be passed from client.
For Mandatory, RequiresNew, Never and Supports, their purpose is to deal with the client's transaction context passed in. That the reason why they are not applicable for MDB.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic