2. The client can safely continue the transaction by retrying the operation if an application exception is received, but only after checking the transaction has not been marked for rollback.
Option 1 says: The client can safely continue the transaction by retrying the operation if an application exception is received. But if EJBContext.setRollbackOnly() has been called before throwing application exception, even if client continues transaction it will not commit. So it's a good idea for a client program to check whether transaction has been marked for rollback and then safely continue.
Note: A lot depends on how one interprets word safely here. If we say safely means without any exception, yes then option 1 also makes sense. But while answering above question I interpreted safely means that it's safe to continue transaction and probability of transaction being rollback is less.
Please correct me if I am wrong.
Regards,<br />Sandesh<br />(SCJCP, SCWCD, SCBCD - 99%, OCP-1)<br /> <br />Either find a way or create one.
Originally posted by Mark Lybarger: i'm on board with jyothi on this one. seems like 1 is correct to me.
if a bean throws an application exception the transaction _may_ be doomed, but the client can't tell. the client can either contine processing (even retry the same operation ).
If a transaction started by the client, client can check if the transaction was marked for rollback or not the same way as BMT beans (using the UserTransaction.getStatus method). So if safely phrase means knowing that the transaction can definetely be committed, then option (2) would be more correct.
However, IMO this is a very ambigiously worded question and I wouldn't lose too much sleep over it