Mock Question

[Vipin Mohan]

hi
Here is a mock question from an IBM sample test. It says this question has 2 correct answers. However I can find only one.
While testing a session bean configured with "Bean Managed", a developer discovers that a TransactionRolledBackException is being thrown by a call to a method on an entity bean. The session bean, prior to calling the method, explicitly started the transaction. Possible causes for the exception are that the:
A. entity bean method is throwing a checked exception and is configured with a transaction attribute of "Required".
B. entity bean method is throwing an unchecked exception and is configured with a transaction attribute of "Required".
C. entity bean does not throw an exception but is configured with a transaction attribute of "Not Supported".
D. entity bean method is throwing an exception and is configured with a transaction attribute of "Requires New".
B is a correct answer. Is there any other correct choice ?
Thanks
Vipin

[Philippe Maquet]

Hi Vipin,
I think C is correct too, because a system exception will be thrown from the entity bean's method because of the "NotSupported" transaction attribute (because the only attributes entity beans support are "Required", "RequiresNew" and "Mandatory").
But it's just my guess...
Best,
Phil.
[ January 21, 2004: Message edited by: Philippe Maquet ]

[Magnus Stattin]

This is a extract from the Revision History in the spec, it seem like it has been hard to decide what transaction attributes should be allowed for entity beans
E.10 Public Draft 2:

Added requirement that the Bean Provider must use only the Required, RequiresNew, or Mandatory transaction attributes for methods defined in the home or remote interface of an entity bean with EJB 2.0 container-managed persistence.

E.13 Final Draft:

Relaxed requirements on transaction attributes for methods of entity beans with container-managed persistence to allow containers to optionally support use of NotSupported, Supports, Never transaction attributes. Added cautions about their use.

It seems like they came to the conclusion that all transaction attributes should be allowed after all...
It is hard to keep up
/Magnus
[ January 21, 2004: Message edited by: Magnus Stattin ]

[Philippe Maquet]

Hi Magnus,

From specs, p. 352) :
For entity beans that use EJB 2.0 container-managed persistence, only the Required,
RequiresNew, or Mandatory transaction attributes should be used for the methods defined in the
bean�s component interface and all the direct and indirect superinterfaces of the component interface,
excluding the getEJBHome, getEJBLocalHome, getHandle, getPrimaryKey, and isIdentical
methods; and for the methods defined in the bean�s home interface and all the direct and
indirect superinterfaces of the home interface, excluding the getEJBMetaData and getHomeHandle
methods specific to the remote home interface. Containers may optionally support the use of the
NotSupported, Supports, and Never transaction attributes for the methods of entity beans with
container-managed persistence. However, entity beans with container-managed persistence that use
these transaction attributes will not be portable.

Magnus:
It seems like they came to the conclusion that all transaction attributes should be allowed after all...

I disagree a bit... Studying EJB specs (instead of any specific vendor implementation) aims to be able to write portable EJB apps. So when I read in the specs that such way of coding/deploying is not portable, it's compelling to me to translate it in "don't do it !".
Anyway, that mock question comes from a vendor-specific test (IBM), and as I wrote above, C as additional correct answer is just my best personal guess...
Best,
Phil.

[Magnus Stattin]

You are right Philippe, this has made me a little bit confused, maybe because of the difference between what is allowed and what is portable.
Thank you for straighten me out
Best Regards

[Vipin Mohan]

Thanks Phil and Magnus for your inputs !
It is understandable, that an entity bean having a 'NotSupported' transaction attribute might throw a SystemException in this case. However, the question is about TransactionRolledbackException. And as far as I know, this exception is only thrown when the client's exception is propogated to the called method and then a rollback happens because of an exception.
Am I correct ?
Thanks
Vipin

[Magnus Stattin]

Hello Vipin
This is what I know about this:
The TransactionRolledbackException will only be thrown when the rollback happens because of an exception in the called method.
As the rollback must be caused by the exception it must be a system exception.
If the called method is just doing a regular rollback with setRollbackOnly() the TransactionRolledbackException will not be called.
The called method have to be in the same transaction as the client, if the called method is in a transaction of its own it is not necessary for the called bean to inform the client about the rollback. The client would get a RemoteException or a EJBException in that case.
Please correct me if I'm wrong. Based on this I'm unable to find a second correct choice. If the method is demarcated with NotSupported and that is not supported by the application server i think that would be known at deploy time and not come as a suprise at runtime. My guess is that it will not even deploy in that case.
/Magnus
[ January 22, 2004: Message edited by: Magnus Stattin ]
[ January 22, 2004: Message edited by: Magnus Stattin ]
[ January 22, 2004: Message edited by: Magnus Stattin ]