4 Replies Latest reply on Dec 13, 2006 1:59 PM by Brian Stansberry

    Problem with order of entity cache operations with Hibernate

    Brian Stansberry Master

      There appears to be a difference in behavior between JBossTM and JBossTS that's leading to failures with JBoss Cache as the 2nd level entity cache.

      JBC handles replication of transaction-scoped cache changes by registering as a transaction Synchronization and replicating the changes during the beforeCompletion() callback. This is failing with JBossTS because the beforeCompletion() callback is being executed *before* the Hibernate flush activity that updates the cache. No activity at time of beforeCompletion() == no replication of the tx's changes.

      2006-11-16 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] Running beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
      2006-11-16 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] Setting up transactional context.
      2006-11-16 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] Setting tx as TransactionImple < ac, BasicAction: -3f57ff9b:a5b:455d4cd6:10 status: 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1
      2006-11-16 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] No modifications in this tx. Skipping beforeCompletion()
      2006-11-16 23:48:41,250 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] processing flush-time cascades
      2006-11-16 23:48:41,250 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] dirty checking collections
      2006-11-16 23:48:41,265 DEBUG [org.hibernate.engine.Collections] Collection found: [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: [] (initialized)
      2006-11-16 23:48:41,265 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3 insertions, 0 updates, 0 deletions to 3 objects
      2006-11-16 23:48:41,265 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1 (re)creations, 0 updates, 0 removals to 1 collections
      ...
      followed by puts into the cache

      When I switched the AS back to using JBossTM, the problem went away -- the Hibernate flush activity occurred first, and then the beforeCompletion() call to JBC.

      I'm speculating that Hibernate is also using a Synchronization to manage the flush, and that JBossTA and JBossTS make the calls to registered Synchronizations in a different order.

      At this point, replication of clustered EJB3 entities is basically broken.