question about EJB transaction

[Timber Lee]

An EJB business method performs an operation that throws a checked exception. The bean cannot
recover from this checked exception and should rollback. The bean will be deployed using
container-managed transaction demarcation. Which implementation is the BEST?

A. public void businessMethod() { try { // operation throwing SomeCheckedException goes here }
catch (SomeCheckedException ae) { throw new EJBException(ae); } }

B. public void businessMethod() { try { // operation throwing SomeCheckedException goes here }
catch (SomeCheckedException ae) { context.setRollbackOnly(); throw new EJBException(ae); } }

C. public void businessMethod() throws EJBException { try { // operation throwing
SomeCheckedException goes here } catch (SomeCheckedException ae) { throw new EJBException(ae); }
}

D. public void businessMethod() throws EJBException { try { // operation throwing
SomeCheckedException goes here } catch (SomeCheckedException ae) { context.setRollbackOnly();
throw new EJBException(ae); } } }}

[Debanjana Dasgupta]

The answer is A
Debanjana

[Timber Lee]

I think D is correct.
because:
1.transaction needs to be rollbacked, so context.setRollbackOnly() should be called.
2.businessMethod() should return a exception to caller, so throw new EJBException(ae) should be executed.
but, caller gets a EJBException, which type it handles the EJBException as, system Exception or application Exception?
I get confused.

[Eduard Manas]

Timber,
The reason why it's A is because javax.ejb.EJBException is a RuntimeException, which are handled differently by the EJB container.
When an EJB throws a RuntimeException, unlike checked exceptions, the container is forced to automatically rollback the transaction (whether you want it or not...). You can also call setRollbackOnly(), but it is unnecesary (thus B and D are false)
The rest is between A and C. As RuntimeException are not required to be defined as part of the throws of the method signature (Java stuff), C is not the best answer.
Eduard