[jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJB Container] - Problemwith order of entity cache operations with Hibernate

[Manik Surtani]

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 at jboss.org
Telephone: +44 7786 702 706
MSN: manik at 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 at 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
>> 5
>>
>>> _______________________________________________
>>> jboss-dev-forums mailing list
>>> jboss-dev-forums at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
>>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>