This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
This is a very concise and short question just to clarify one concept.
What happend if in the middle of a EJB transaction-REQUIRED method, a RequiresNew-method in another EJB is called, and this RequiresNew-method happens to throw a System Exception ? ... and what happend if it throws an application exception ? .. I mean, what happend with the transaction of the first calling method ?, if it rolls back, as i think it should ,,, whats the difference, from the developers view, between a REQUIRED-method and a RequiresNew-Method ? ... I know the theory ... it must start a new transaction ... but ... whats the difference if it do not start a new one, and just is included in the transaction scope of the calling method ?
What happend if in the middle of a EJB transaction-REQUIRED method, a RequiresNew-method in another EJB is called, and this RequiresNew-method happens to throw a System Exception ?
B1 - with Tx1 calls B2 with Tx2 (new). And then B2 throws System Exception. Since the Container manages the System Exception it will :
1. Log the exception 2. Rollback Tx2 3. Discard the instance of B2 and throw EJBException to B1 with Tx1.
Now it is upto B1 with Tx1 how to handle the EJBException. If it doesn't catch and ignore it then an EJBException being raised from B1 would result in the same sequence of steps taken by container as above. i.e Tx1 would also rollback.
.. and what happend if it throws an application exception ? ..
For Application Exception - if the exception is marked with the flag rollback=true or if B2 marked the Tx2 for rollback using setRollbackOnly then the container rollback the Tx2 and forward the application exception.
It is upto the Bean B1 to either eat up the application exception and continue to work in Tx1 or forward it back to the calling client i.e rethrow Application Exception - In this case - the behavior of the container would be same as worked for B2/Tx2.
See - if the Tx is same for bean B1 and B2 - then the container starts to take action in rollback/commit in the bean which actually started the Tx. Otherwise container propagates exception (and/or) logs exptn,discards the instance only.
But if Tx is different for both beans then actions are taken per bean where Tx started and then Exception propagated to the caller.
The one who starts the Tx has the control - that is the difference...