Our application is using the basic "session bean facade - thread local session - Hibernate-driven domain layer" model. All is basicall well.

One of the key layers of our system is a distributed job handling framework, where all state relating to concurrent jobs lives in the database, and where jobs are farmed out to multiple machines with JMS. We are trying to arrange the scheduling logic so it is truly distributed (i.e. no centralized scheduler, coordination done via the database).

The basic scheduling operation is "do some more work on the oldest existing job." It is possible that multiple machines may try to do more work concurrently, in which case they may wind up updating the same job records. In other words, locking issues are lurking. We are still early in development so we have not seen them yet, but I know they are in there.

Pessimistic locking could lead to various kinds of deadlocks, though I have hopes that selective LockMode.UPGRADE requests will help with that. But let's say pessimistic locking turns out to be too slow or too fragile and we want to go with optimistic locking.

Now come my questions.

- When using optimistic versioning, if we get a StaleObjectStateException, this means that we need to discard the whole session, right?

- When using ThreadLocalSession, if we discard the whole session, we may perhaps have to discard all work being done in the bean invocation, right?

- In other words, is it true that using container-managed transactions together with optimistic versioning generally requires a version mismatch to roll back the entire bean operation?

I know these questions are probably addressed in the Hibernate book, but I'm signed up for the Manning EAP already; what more do you want from me?! ;-)

Cheers!
Rob

Yes to all of your questions except if you open a new session somewhere

But if you open a new session, it'll get associated with the same transaction, correct? In other words, with default "Required" transaction attribute on a bean, you get only one container-managed transaction per bean method invocation... so if you get a StaleObjectState exception in your Session, the only way to roll back the work (that you now don't want to commit because it is stale) is to roll back the entire method invocation. So how can you open a new session if you're rolling back the entire transaction that the container has opened for you?

Cheers,
Rob

CAll a new EJB in requiresNew.
But you're basically right and I usually avoid recover of session failure.