aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Wrong answer/explanation in com.enthuware.ets.scbcd.v5.2.161 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Wrong answer/explanation in com.enthuware.ets.scbcd.v5.2.161" Watch "Wrong answer/explanation in com.enthuware.ets.scbcd.v5.2.161" New topic
Author

Wrong answer/explanation in com.enthuware.ets.scbcd.v5.2.161

Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
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.

Remarks:

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.

3. The same holds for stateless session beans.



SCJP 5 (98%) - SCBCD 5 (98%)
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3293
    
    7
Hi Ralph,

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?


Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
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.

Raf
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
Hi Paul,

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.

Raf wrote
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.
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
/
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Wrong answer/explanation in com.enthuware.ets.scbcd.v5.2.161