doubt on mock question

[bhilla ratna]

UserTransaction ut = validContext.getUserTransaction();
The following code is given

ut.begin();
//some more valid code
...
ut.setRollbackOnly();
//some more valid code
...
ut.commit();

a The bean might be a Message Driven Bean.

b The bean must not be a stateful session bean.

c This must not be a stateless session bean.

d This code will throw an exception at runtime.


e This code will not compile.


f The bean must be an entity bean with bean managed persistence.


g Upon execution of this code, the container ensures that the transaction is not committed.

Answers are a and g

I don't understand why g? I think a and d.

bhilla

[Prashant Neginahal]

Bhilla,

Why do u think answer is d? When u execute ut.setRollbackOnly(), the transaction is marked for rollback. And, after executing commit(), the container sees that this transaction is marked for rollback, so will not commit it.

Thanks,
Prashant

[sawan parihar]

Hello bhila,

g)Upon execution of this code, the container ensures that the transaction is not committed

If the transaction is already marked for rollback then container will make sure that it will never commit. This makes the option g correct.

d This code will throw an exception at runtime.

This is also correct. Most of the container will throw error in this case. But then it again depends upon the container implementation. In case of weblogic "AppSetRollbackOnlyException" will be thrown. I am not very sure that what specs say about this but I believe that its upto the container provider.

Hope it helps.

[Ådne Brunborg]

This is also correct. Most of the container will throw error in this case. But then it again depends upon the container implementation.

I don't see why this code would throw an exception, please enlighten me...
[ August 12, 2005: Message edited by: �dne Brunborg ]

[sawan parihar]

I don't see why this code would throw an exception, please enlighten me...

The exception will be thrown because we are trying to commit a transaction that is alreday marked for rollback. It will be helpful if for example we consider weblogic. It throws AppSetRollbackOnlyException to indicate that a transaction was marked for rollback by an application component.

http://e-docs.bea.com/wls/docs81/javadocs/weblogic/transaction/AppSetRollbackOnlyException.html

Hope it helps.

[Ådne Brunborg]

Yes, it helps, thanks, but - this exception is vendor-specific. So, is it the code which throws the exception, or is it the container?

[trying hard to understand exactly what happens here]

[Roger Chung-Wee]

The container may throw an exception, so d is incorrect.

Note that if weblogic.transaction.AppSetRollbackOnlyException were thrown (upon invocation of ut.commit()), then this exception should be handled by logging it for a message-driven bean. It would not make sense for a checked exception like this to be thrown from an MDB as there is no client.

[seemapanth Joshi]

This is the process of thinking out aloud and please tell me if the following explanation in support for the original answers are correct.

1. This code might be MDB.
2. if it is MDB, it is Bean Managed.
3. So call to setRollbackOnly() itself will throw an exception IllegalStateException but in case of MDB, it will be logged.
4. And since the exception is System exception, it would prevent the method from successfully completing. Spec page 377. And thus container will ensure that rollback occurs.
[ August 14, 2005: Message edited by: seemapanth Joshi ]

[Dhondiba Joshi]

Hi

I think the code is definitely BMT but need not be MDB. It can be any of the session beans. Correct me if i am wrong. i agrre on initial answers a and g to be correct.

[Roger Chung-Wee]

I would say that the code can be found in any type of bean except entity bean, which must be CMT.

[Praveen Kumar Mathaley]

option d should also be correct, if doesn't throw the exception then how will it know about the rollback!, when the transaction is rolledback , should throw the exception , to inform that the transaction has been rolledback! when one say's the code throws exception at runtime,
it's logical to assume that the container throws the exception to code and code throws the same!

[Roger Chung-Wee]

Rollback can also be achieved by UserTransaction.setRollbackOnly.