No, not possible right now. This problem roots to JTA, we really should push the ability to: 1. guaranty synchronization ordering 2. query/alter the synchronization list in a standard way. 1. is not possible today and javax/transaction/TransactionSynchronizationRegistry is way too limited 2. is useful when writing frameworks on top of JavaEE as a way to keep state / avoid multiple synchronization on a per transaction basis. Manik Surtani wrote: > > Not sure, cc'ing Hibernate-all. Even if there was such an ordered > sync handler, we'd have to expose a mechanism to have this injected. > Perhaps via the Runtime. -- > Manik Surtani > > Lead, JBoss Cache > JBoss, a division of Red Hat > > Email: manik(a)jboss.org > Telephone: +44 7786 702 706 > MSN: manik(a)surtani.org > Yahoo/AIM/Skype: maniksurtani > > > > On 17 Nov 2006, at 15:43, Brian Stansberry wrote: > > <SNIP /> > >> That's how we find such a thing. Anyone have any good thoughts on >> what to do about it? Perhaps Hibernate exposes something like JBC's >> OrderedSynchronizationHandler, which the JBC integration can use to >> insert it's synchronization at the correct point? > > Manik Surtani wrote: > >> Hmm, the *correct* approach to dealing with this would be to put >> together a series of integration tests for JBoss Cache and >> Hibernate, exercising such scenarios with different TMs, and making >> sure these are run with every release of Hibernate and JBC. Either >> that, or we assume the EJB3 test suite covers this, and I presume >> this is how you uncovered this issue? >> >> >> >>> FYI; just posted on the EJB3 forum. >>> >>> bstansberry(a)jboss.com wrote: >>> >>>> 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. >>>> >>>> View the original post : >>>> >>>> >>> http://www.jboss.com/index.html? >>> module=bb&op=viewtopic&p=3986745#3986745 >>> >>>> >>>> Reply to the post : >>>> >>>> >>> http://www.jboss.com/index.html? >>> module=bb&op=posting&mode=reply&p=398674