This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Which of the following are true regarding a bean with bean managed transaction demarcation ?
a) the bean must be a session bean or a message-driven bean
b) The bean instance that starts a transaction must complete the transaction before it starts a new transaction
c) The bean may use nested transactions
d) If it is a stateless session bean, it must commit a transaction before a business method or a timeout callback method returns
e) If it is a message-driven bean, it must commit a transaction before its message listener method returns
The correct answers are a), b), d)
I agree that these are correct, but e) is correct, too.
e) is considered incorrect with the explanation
"This is not fully true. A message driven bean may commit the transaction even in a timeout callback method."
However, core spec 13.6.1 states
If a message-driven bean instance starts a transaction in a message listener method or interceptor method, it must commit the transaction before the message listener method (or all its interceptor methods) returns.
1. enthuware's explanation may be based on a misinterpretation of core spec 13.3.3:
A message-driven bean instance must commit a transaction before a method listener method or a timeout callback method returns.
2. From a functional point of view: core spec 18.2
The timeout callback method invocation for a timer that is created for a stateless session bean or a message-driven bean may be called on any bean instance in the pooled state.
If the instance that performs the timeout callback method can be choosen arbitarily, how should it know that it has to complete a transaction started by a message-listener method of some other instance ? This couldn't work.
Hi, I agree with Ralph. The statement in the specs is a little misleading in my opinion. What it really means is: when a transaction is started in a timeout callback, it must end in the same callback. If it is started in a listener method, it must end in the same listener method (note that interceptors are a kind of listener method extensions, so a transaction could as well be started and finished in an interceptor).
What the question and the text from the specs suggest is: when a listener method starts a transaction, it may finish in timeout callback, and vice versa. At least that is what I concluded.
Also, to back my opinion, I had a very similar question on my exam, and I marked " If it is a message-driven bean, it must commit a transaction before its message listener method returns" (slightly different wording), and judging by my score, I had this one right. I remember this one specifically as I had the same doubts as Ralph is having right now.
For example, if a listener method starts a transaction, and creates a timer, and the timer is to be fired in 12 months, letting the timer callback commit the transaction would leave the transaction running for a year, which is simply not conceivable.
As for the question, I think it could be more specific, and maybe mark in the explanation that it explains what the specs didn't explain clearly enough (at least, in my opinion, and this question this kept me thinking for quite some time). I think that instead of requiring the user to remember the exact wording from the specs, it should say that a transaction started in timeout callback / listener method (interceptor) must be finished in the same timeout callback / listener method (interceptor), respectively.
Whenever "listener method" phrase is used, "stateless session bean business method" may be used as well.
Joined: Apr 27, 2008
What, in your opinion, is the correct interpretation of 13.3.3 ?
"A message-driven bean instance must commit a transaction before a method listener method or a timeout callback method returns."
Do you think it is a mistake in the spec or it might be applicable in some other scenario?
I wouldn't call it a mistake. It's just a shorthand version of the comprehensive formulation given in 13.6.1:
If a message-driven bean instance starts a transaction in a message listener method or interceptor method, it must commit the transaction before the message listener method (or all its interceptor methods) returns [...]
If a session bean or message-driven bean instance starts a transaction in a timeout callback method, it must commit the transaction before the timeout callback method returns.
I had the same doubts as Ralph is having right now.
There is no doubt. Spec in 13.6.1 is unambiguous and enthuware's explanation concerning e) also contradicts the stateless nature of MDBs.