Hi all,

I would like to intercept all optimistic-locking-related exception so that we can deal with it sensibly. We are using CMT (with JBoss), so there is no transaction demarcation within the code.

I see Hibernate 3 has the listener concept. So, I create my listener that extends off the DefaultFlushEventListener, with its sole purpose to intercept the StaleStateException and throwing my own application exception. A couple of questions:

1) Is it ok to rethrow the StaleStateException as something else at this level?
2) Is there any other listener I need to implement to catch optimistic-locking related exception?

Thanks in advance,
Liem

A note is that my application exception is also a RuntimeException.

Anyone with this need out there? I assume the need to be notified for an optimistic-lock exception should be a good one, since that is one of the few HibernateException that the application can do something about it.

Liem

JAVA "catch" block listens for exceptions, do you need something "better" ?

not too sure if "we can deal with it sensibly" other than to retry the unit of work or redirect the user to a pretty error page. have heard more than once on the forum that if you get any exception in the Session - rollback transaction and throw away the Session.

It is common to forward request to the same page with the same data and message "$data was modified by $user .... " on version conflict, so just catch exception, rollback transaction and close session, if you need modified data then load it in the new session. But it must be better to avoid this exception using hidden version field in HTML form without any state on webserver, it can help to avoid scalability problems.

Hi,

Thanks for all your suggestions...

But, remember I am in CMT, so all transaction demarcations are done declaratively. I don't get the exception until the container tries to commit, fails, and rollbacks the exception, in which case the client gets a RemoteException which wraps a JBossRollBackException which wraps the Hibernate StaleObjectStateException.

So, now you see, I have to do 2 things to handle this--not sure if this is the recommended way to do it:

1) Introduce another higher-level facade business layer, which calls the transactional layer that does Hibernate stuff, so that I catch this particular RemoteException and retry.

2) I need to specifically "peel" off the RemoteExeption 2 levels down and look for this particular StaleObjectStateException to detect an optimistic-lock failure. Other Hibernate failures are considered non-recoverable by us.

My point is, since the StaleObjectStateException is so "special", I think there is great value to have a notifier for it, so applications can choose to handle it or not.

Also, back to my original question...

Is it sufficient to "catch" optimistic-lock exception by extending off the DefaultFlushEventListener, intercepting the StaleStateException and throwing my own RuntimeException?

Is there any other listener I need to implement to catch optimistic-locking related exception?

Thanks,
Liem

Should the StaleObjectStateException notification be an enhancement request for Hibernate? Before I file a JIRA, just want to make sure that there are enough people out there with similar needs as I do. Of course if there is another sensible workaround, then I will buy that too :)

Thanks,
Liem