• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


 
Enthuware Software Support
Posts: 4896
60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
/
 
Humans and their filthy friendship brings nothing but trouble. My only solace is this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic