I would like some input on the following, which is not a bug but a design question:

I?m developing an application using the EJB3 API, where I use optimistic locking for long transactions. The create, update and delete methods on my DAO interfaces declare an application specific VersionException, that is to be thrown by the server when supplied with outdated data, resulting in a transaction rollback.
The client is then supposed to handle the exception, either by displaying an error message to the end user, or automatically reloading and retrying in some cases, for instance when a customer attempts to update his or hers password.

The EJB3 draft specification supports the first part of this scenario through the @Version annotation, but I can?t find anything about how an exception caused by invalid versioning is to be reported back to the application. On Jboss-EJB-3.0_RC1 I get an org.hibernate.StaleObjectStateException in my test cases. Does this mean I have to create Jboss/Hibernate specific code to catch this exception and throw my application exception?

I figured the best way to handle this is to create an interceptor that does nothing but catching StaleObjectStateExceptions and throwing them as VersionExceptions to the client, but of course, this interceptor would have to be changed in order to deploy on other application servers.

Btw, I think the same problem occurs if one wants to throw application specific ObjectDeletedExceptions to clients that supply the server with deleted objects. From reading the Hibernate Javadoc I guess this also would result in a StaleObjectStateException.

Any input is highly appreciated, and keep up the good work!
Regards
Trygve