About Question enthuware.oce-jpad.v6.2.409 :

[johnlong]

Please explain why transaction should be marked for rollback, if it is not specified to cause rollback

If the application exception is not specified to cause transaction rollback, mark the transaction for rollback

Do you mean that transaction shall be marked as rollback only in case there is a thread to data integrity?

Second question:

Mark the transaction for rollback using the EJBContext.setRollbackOnly

What about marking transaction for rollback via @ApplicationException(rollback=true) ? Should it be via EJBContext.setRollbackOnly or via @ApplicationException(rollback=true).

[admin]

1. If the bean cannot recover from this exception, there is something seriously wrong and the business workflow is affected. It is the bean's providers responsibility to mark the transaction for rollback in such a case because the container will not automatically roll back the transaction.

2. It is talking about the case when the rollback=true is not specified on the application exception. So obviously, setRollbackOnly is the only option left.

[johnlong]

Thank you.

[himaiMinh]

For option 2, if the checked exception is an @ApplicationException, it should be thrown as it is , not wrapped by EJBException. So, I think option 2 may not be true.

Also, in option 2, it says the checked exception is not listed and cannot be recovered. It implies that the checked exception is a subclass of RuntimeException , annotated by @ApplicationException. If that is the case, this exception should not be wrapped.
If the checked exception is a system exception, then option 2 applies.
So, in option 2, which type of exception (application or system) it is referring to?

[admin]

A checked exception implies that it is NOT a subclass of RuntimeException.

An exception that is annotated with @ApplicationException is an application exception irrespective of whether it is a checked or unchecked exception.

[himaiMinh]

OK. I see. One more question, the option 2 says the checked exception not listed in throw clause and the bean cannot recover from it.
Since checked exception is not a subclass of Runtime exception, it should be listed in the throw clause of the bean's method and the bean should be able to recover from it.

It seems to me that option 2 is referring to an unchecked exception, not a checked exception.

[admin]

No, the option is correct. It is talking about a situation where your bean method code calls some other method and that other method throws a checked exception but it is not listed in the throws clause of your bean's method. Like this -

Code: Select all

void mymethod() {

   try{
       someOtherMethod();
   }catch(SomeCheckedException sce){
      throw new EJBException(sce);
   }

}

[__JJ__]

If it is a checked exception, from which the bean cannot recover, throw the exception as it is.
In such a case, the bean provider must ensure that the transaction is never committed and the instance is discarded. To achieve that he must throw a system exception. This can be done by wrapping the exception into an EJBException and rethrowing it. EJBException is a system exception and this will ensure that the transaction will never be committed and instance will be discarded.

If you throw the checked exception as it is (if it is listed in the throws clause), transaction will not be automatically set for a rollback and there is a possibility that the client my still try to commit it.

This is muddying the waters by using checked exception and system exception. Table 15 of the ejb spec specifies AppException and "all other exceptions". Table 15 also specifies only Appexceptions as to be re-thrown as-is to the client. Considering that an appexception is a checked exception (because system exceptions are runtime exceptions), then it looks very much like this answer is correct.

Furthermore, instance discard, logging and transaction (if one exists) rollback occur with system exceptions, which are not checked exceptions, so the first line of the explanation does not make sense:

"In such a case [checked exception ie appexception], the bean provider must ensure that the transaction is never committed and the instance is discarded."

How can that not be the case?

Thanks.

[__JJ__]

Also this:

If the application exception is not specified to cause transaction rollback, mark the transaction for rollback using the EJBContext.setRollbackOnly method before throwing the application exception. Marking the transaction for rollback will ensure that the transaction can never commit.

This means, effectively, regardless of whether the application exception is specified as causing txn rollback, the txn will get rolled back:
1, it's specified as causing rb ==> gets rolled back
2, it's NOT specified as causing rb ==> roll it back anyway

Is that correct? If so, why bother having the rollback annotation in the first place, if every application exception is supposed to get rolled back, always?

[admin]

>Considering that an appexception is a checked exception (because system exceptions are runtime exceptions)
Even a runtime exception can also be an application exception, if you annotate it with @ApplicationException

The statement is option 2 clearly says, "...and if the bean cannot recover from this exception, ...". So if the bean code receives a checked exception and if the developer wants to make sure that the transaction is rolled back is this case, the bean must throw a system exception to the container. Wrapping the exception into an EJBException is a sensible course of action in this case.

I think you might be misinterpreting the option. Option 2 is actually talking about how to achieve a particular objective, which is, to roll back the transaction if the bean receives an application exception. As you have noted, an application exception does not always cause the transaction to roll back automatically. But this is what is required in this case. So how will the developer do that? By wrapping the exception into an EJBException and throwing that exception to the container.

[rubyatiy]

Also this:

If the application exception is not specified to cause transaction rollback, mark the transaction for rollback using the EJBContext.setRollbackOnly method before throwing the application exception. Marking the transaction for rollback will ensure that the transaction can never commit.

This means, effectively, regardless of whether the application exception is specified as causing txn rollback, the txn will get rolled back:
1, it's specified as causing rb ==> gets rolled back
2, it's NOT specified as causing rb ==> roll it back anyway https://phenq-reviews.com/australia/

Is that correct? If so, why bother having the rollback annotation in the first place, if every application exception is supposed to get rolled back, always?

Those who are not depending with there authentication are not supported