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

[Brian Stansberry]

I've resurrected this thread on the JBC Dev Forum at
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97247.

This is suddenly more urgent because JBossTS is going into AS 4.2.

Emmanuel Bernard wrote:
> 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 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