1 Reply Latest reply on May 23, 2006 5:56 AM by Matt Accola

    Optimistic cache and PROPAGATION_REQUIRES_NEW

    Matt Accola Newbie

      Don't know if I am doing something wrong here, please help.

      I am using JBoss Cache 1.3.0.SP2 with Hibernate 3.2.CR2. I am getting the dreaded "org.jboss.cache.CacheException: unable to validate nodes" exception caused by:

      INFO [WebContainer : 0] (org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor:?) 2006-05-23 00:46:28,518 - DataNode [/org/hibernate/cache/StandardQueryCache] version DefaultDataVersion(35) is newer than workspace node DefaultDataVersion(33)

      Since I was positive there was only one thread executing at the time I went back to see how the version number on the StandardQueryCache could have been incremented within a single transaction. Turns out I have one main transaction with PROPAGATION_REQUIRED and during the execution I make two calls to transactions with PROPAGATION_REQUIRES_NEW. The two new transactions will suspend the main transaction, execute a query among other things, and commit the transaction (which causes the cache to increment the version on the StandardQueryCache), and then resume the main transaction.

      This is the log statement I see when the "nested" transactions commit:

      Setting version of data node org/hibernate/cache/StandardQueryCache from DefaultDataVersion(34) to DefaultDataVersion(35)

      As a side note I am puzzled as to why the query is even going into the StandardQueryCache at all because the query is not flagged as cachable in Hibernate and all my unit tests (which do not use optimistic locking due to the lack of a transaction manager) do not show the queries being stored in the StandardQueryCache.

      How is this how it is supposed to work? Seems like PROPAGATION_REQUIRES_NEW is not supported with optimistic cache. The only way I can get around it now is to disable query caching globally in Hibernate.