I wanted to confirm with the community a conclusion I've come to about long-lived Sessions, following the Session-per-App-Transaction pattern. In a nutshell, this is that applications are expected to manage Sessions "optimisitically" -- do not repeatedly check if persistent objects in the Session are stale (inconsistent with the database state) but rather assume they're up to date. This is analogous to the optimistic locking approach Oracle recommends for working with the database itself: assume data has not been modified by another transaction.

I understand why, in general, the optimistic approach scales best. However, the web app I'm developing is in some ways closer to a thick client/Swing app as we expect relatively few concurrent users with large "working sets" in each user's Session. That's why we favor the Session-per-App-Txn pattern.

But we keep bumping into the recommendation in the docs that Sessions should be discarded whenever an exception is thrown; e.g., by a version check failure encountered while locking with LockMode.READ. I posted an inquiry about locking in the beginner's forum.

Then there are notes in the Javadoc, like this one for Session.refresh():


What kind of "special circumstances" are envisioned? What are good rules of thumb for apps using long-lived Session to do version checks and/or refresh persistent objects? Is this discouraged for performance reasons, to keep things simple, or what?

The user manual suggests that it's OK to force version checks when reconnection long-lived Sessions:


Is the expectation that the Session will be discared, as opposed to just refreshing the stale data? That seems to defeat the purpose of long-lived Sessions.

Thanks!

Upon further investigation I've learned that the locking mechanism is not a reliable way to check an object version number in that locks can only be acquired once per transaction. Hence, only the first time a lock is acquired within a transaction will Hibernate actually access the database; successive attempts do nothing.

This makes sense from the perspective of how locks are managed, since Hibernate just delegates this responsibility to the database and database locks can usually only be revoked by rolling back the transaction or released by committing the transaction. I can only see the logic for this behavior in terms of an optimistic locking strategy: why should an application repeatedly check an object's version number within a transaction? With long-lived Sessions, checking the version number each time the Session is reconnected (starting a new transaction) should be sufficient.

Hope this information is useful to some of you; perhaps it was self evident to most ;)