Graceful recovery from StaleObjectStateException

JonC · **Joined:** Wed Jan 28, 2009 3:49 pm **Posts:** 3

Hi. I'm using Hibernate 3.2.5 with an EHCache.

The code below, on an entity declared with a <version> in it's mapping, fails with StaleObjectStateExceptions that I can't seem to recover from, even though I try many times to reload the current state.

Code:

// update service statistics when a resource is fetched from a resource manager
for(int attempts = 1; attempts <= lockRetryAttempts; attempts++) {
    try {
        session.evict(manager);
        manager = (ResourceManager) session.load(ResourceManager.class,
            manager.getId(), LockMode.READ);
        // sleep for a few seconds here to highlight concurrent updates
        manager.setFetchedBytes(manager.getFetchedBytes() + resource.getSize());
        manager.setFetchedFiles(manager.getFetchedFiles() + 1);
        session.flush();
        break;
    } catch(StaleStateException e) {
        if(attempts == lockRetryAttempts) {
            throw e;
        }
    }
}

So, how can I get Hibernate to do what I'm trying to do? Which is, when catching a StaleObjectStateException, to force it to reload the record and try again.

JonC · **Joined:** Wed Jan 28, 2009 3:49 pm **Posts:** 3

Bump? Any ideas? It can't be that uncommon, to want to catch and recover from what should be an unexceptional and expected event when dealing with optimistic locking?

mmerder · **Posted:** Tue Feb 17, 2009 6:49 am

Try to get a new session, as you should not use the same session after an error occured.

JonC · **Joined:** Wed Jan 28, 2009 3:49 pm **Posts:** 3

Is there really no better way? It just seems a bit wasteful and inefficient to have to rollback and tear down the session, create a new one, start a new transaction, and redo (somehow...) all the updates to that point just to retry an optimistically locked update, when all that's failed is the 'WHERE version = :currentversion' part of an update during the flush returned 0 rows updated.

Why can't I just refresh the state of the stale object and attempt the update again, with the version counter now current? Like I said, detecting a version conflict on a heavily contended table is hardly an exceptional circumstance, so why does Hibernate seem to demand such drastic corrective action as destroying the session and restarting if I catch it and try to handle it?

mmerder · **Posted:** Wed Feb 18, 2009 6:41 am

I guess, there is no "better" way. See http://www.hibernate.org/hib_docs/v3/reference/en-US/html_single/#transactions-demarcation-exceptions.
I think it won't be to inefficient to use a new session. Obtaining a new session is not very expensive and you could merge your "dirty" objects to do the updates.