It seems that the ejb spec needs to be extended a little to integrate the
issues of transaction isolation level, such that we can handle the
conditions in a portable way.
Currently, if you are using Oracle with an isolation level of SERIALIZABLE,
you have to look out for the ORA-08177 exception. But you don't get
this exception explicitly. The container will throw a RemoteException
to the caller of the transactional ejb method which encountered the
problem. This RemoteException must then be parsed, somehow,
to look for the vendor specific string "ORA-08177"....
Better to have the ejb spec define a new exception type, which is
a sub-class of RemoteException, called:
TransactionSerializationException
So the bean developer/user can just catch this exception and retry
it.
The next step, is to allow the container to automatically retry the
transaction, if it is receives a serialization exception. Of course,
this should be a configurable option at deployment, since the
method might not always have repeatable behavior. But the
bean developer should have this option, if they happen to write
their transactional methods cleanly.
The bottom line is, the ejb layer should not be required to do
specific calls to support specific databases, not with container
managed persistence, anyway. The generalized behavior
embodied by "TransactionSerializationException" handles
this. Any database which implements optimistic locking
would be able to count on the same support by the ejb
developer.
Jason
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
