Enthuware

An observation for D: As the Javadoc says, an EJBTransactionRolledbackException may mean that the TX has been rolled back, or marked for rollback. So you can't know for certain that "the transaction has been marked for rollback". it may have been rolled back already.

This has been updated. Thanks for your feedback!
-Paul.

Why the answer:
"If the client receives EJBException, it can assume that the transaction will never commit." is not true? Because there may be no transaction at all?

jszczepankiewicz wrote:Why the answer:
"If the client receives EJBException, it can assume that the transaction will never commit." is not true? Because there may be no transaction at all?

As the explanation says, "EJBException does not tell anything about the status of the transaction. If the client executes in the context of a transaction, the client’s transaction may, or may not, have been marked for rollback by the communication subsystem or target bean’s container."
This can happen when the caller's transaction is not same as the called method's transaction (e.g. in case of RequiresNew). In this case, if the caller receives EJBException, you cannot be sure that the caller's transaction has been marked for rolled back.

HTH,
Paul.

An observation for D: As the Javadoc says, an EJBTransactionRolledbackException may mean that the TX has been rolled back, or marked for rollback. So you can't know for certain that "the transaction has been marked for rollback". it may have been rolled back already.

To my understanding the transaction has not been rolled back, the container has only marked the transaction for rollback just before throwing an EJBTransactionRolledbackException to the client

This is what the specifications say:

14.4.2.1javax.ejb.EJBTransactionRolledbackException, javax.ejb.TransactionRolledbackLocalException, and javax.transaction.TransactionRolledbackException
If a client receives one of these exceptions, the client knows for certain that the transaction has been marked for rollback. It would be fruitless for the client to continue the transaction because the transaction can never commit.

Regards,
Frits

fjwalraven wrote:

An observation for D: As the Javadoc says, an EJBTransactionRolledbackException may mean that the TX has been rolled back, or marked for rollback. So you can't know for certain that "the transaction has been marked for rollback". it may have been rolled back already.

To my understanding the transaction has not been rolled back, the container has only marked the transaction for rollback just before throwing an EJBTransactionRolledbackException to the client

This is what the specifications say:

14.4.2.1javax.ejb.EJBTransactionRolledbackException, javax.ejb.TransactionRolledbackLocalException, and javax.transaction.TransactionRolledbackException
If a client receives one of these exceptions, the client knows for certain that the transaction has been marked for rollback. It would be fruitless for the client to continue the transaction because the transaction can never commit.

Regards,
Frits

I think a transaction that has been rolled back will satisfy the test for a transaction that has been marked for roll back. So it is certain that a transaction has been marked for roll back (as the specification says), on top of it, the transaction might have been rolled back as well (as the javadoc says). The name of the exception also indicates that the roll back might have happened already.

What do you think?

I think a transaction that has been rolled back will satisfy the test for a transaction that has been marked for roll back.

I am not sure whether that is true, because I doubt that you can still do the test..

I have checked all places in the specs and the only places that the container throws an EJBTransactionRolledbackException is when the bean instance is executing in the client’s transaction (and it then marks the transaction for rollback)
14.3.1 Exceptions from a Session Bean’s Business Interface Methods and No-Interface
14.3.7 Exceptions from Other Container-invoked Callbacks

In all the other cases, when the transaction is rolled back by the container, an EJBException is thrown to the client.

My conclusion, based on the specs is that the API is not entirely correct here.

Regards,
Frits

fjwalraven wrote:

I think a transaction that has been rolled back will satisfy the test for a transaction that has been marked for roll back.

I am not sure whether that is true, because I doubt that you can still do the test..

Do you mean if you call getRollbackOnly() on a Transaction that has been rolled back, it will return false?
That really doesn't make sense.

Do you mean if you call getRollbackOnly() on a Transaction that has been rolled back, it will return false?
That really doesn't make sense.

I think that getRollbackOnly(), according to the API, will return false on a rolled-back transaction.

getRollbackOnly

boolean getRollbackOnly() throws java.lang.IllegalStateException

Test if the transaction has been marked for rollback only. An enterprise bean instance can use this operation, for example, to test after an exception has been caught, whether it is fruitless to continue computation on behalf of the current transaction. Only enterprise beans with container-managed transactions are allowed to use this method.

Returns: True if the current transaction is marked for rollback, false otherwise.

Regards,
Frits

Frits, I guess you are right. Can't really argue much with the Specs or API

The API at http://docs.oracle.com/javaee/6/api/jav ... ption.html
says

This exception is thrown to a remote client to indicate that the transaction associated with processing of the request has been rolled back, or marked to roll back.

So, according to the JSR 318, EJBTransactionRolledBackException indicates that the transaction started by the client, is marked as rolled back.
But according to the API, this transaction indicates the transaction started by the client has been rolled back or is marked as rolled back.

Another notes for everyone, based on my understanding:
getRollbackOnly() = true indicates that a transaction has been marked for rollback.
But if the transaction has been rollback, the getRollbackOnly() = false.