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

[Manik Surtani]

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?

--
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 06:02, Brian Stansberry wrote:

> 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