I have a question pertaining to EJB Transactions.
Application Server :Orion 1.5.2
Operation System : Windows NT
Database: Oracle 8i
Database Driver : Oracle thin driver
I have coded a session bean (lets call it SB1) with a method (method1_SB1). This
methods takes in two integers (say int1 and int2) . It then fires two SQL queries
The first one is
"update table1 set field1 = field1+1 where id ="+int1
The second is intentionally coded with incorrect table name
"update kjkgjdk set field1 = field1+1 where id ="+int2
Now I do not trap any exception (instead throw the SQL exception)
and hence cannot call setRollbackOnly. The record in table1 gets updated while
the other throws an exception.
If I catch the SQL exception and call setRollbackOnly on it, then it does not update
the first table either (something that I accept).
THE QUESTION !!!
Is it mandatory for me to call setRollbackOnly everytime there is an exception or are
there some exceptions that the container would trap and rollback the transaction
if those exceptions are thrown by the methods.
POINT OF DISCUSSION:
I was under the impression that there would be some exceptions atleast which would
force the container to roll back the transaction in case there are some exceptions.
One of the case is that of forced server shutdown. Obviously there would be no guarantee that
my code would be executed and hence the the execution could be terminated just after
the execution of the first query.
Any suggestions ??
If you throw EJBException, or something that extends it, your transaction should be rolled back.
However, I'd have thought that the SQLException should have rolled back automatically. But I'm not sure.
What i assume is that you want both of your transactions to be exceuted separately.
I suggest that you can use UserTransaction object method begin() and commit() accordingly where u find most suitable.
Where are the two transactions? There is only one transaction involving two updates.
If a system exception (subclass of RuntimeException) is thrown, the container will roll back the transaction. For all other application exception (e.g., SQLException) , transactions need to be rolled back explicitly.
Hope it helps.
The container will explicitly roll-back transactions when it gets a system-exception from the bean. A System exception is defined to be every throwable except application exceptions. Application exceptions are subclasses of Exception that are not subclasses of either RuntimeException or RemoteException.
Since SQLException fit the definition of an application exception, they are handed back to the client and do not cause a rollback. If you want to cause a rollback, you can catch the exception and throw EJBException instead (exposing SQLException to the client is a bad idea IMO but that's a different debate).
You should note that throwing a system exception has other implications like discarding of an instance, and it may cause some performance overhead (not large though).