+10 on JBC/Hibernate integration testing too, but whose responsibility +would be to deal with them and make sure that they work? Hibernate or +JBC developer's? Rather than splitting responsibility, I think it'd be +easier to have someone in charge of it who would lease with the rest of +Hibernate and JBC developers, but this is different topic already... +:-) I sent an email a month ago about the possibility of creating a Hibernate/JBC compatibility matrix but not a single person replied. These tests would give us the information we need for this. Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/ -----Original Message----- From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian Stansberry Sent: 17 November 2006 16:44 To: Manik Surtani Cc: jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate +10 on JBC/Hibernate integration testing. The EJB3 testsuite has one test in this area, which luckily uncovered the issue. Only uses the TM that's integrated in the AS; it was a lucky hit. There should be more EJB3 tests as well, but the primary place for it should be in Hibernate/JBC. E.g. this issue quite likely impacts non-EJB3 Hibernate as well. 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 >> 5 >>> _______________________________________________ >>> jboss-dev-forums mailing list >>> jboss-dev-forums(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums >> >> _______________________________________________ >> jbosscache-dev mailing list >> jbosscache-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosscache-dev _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev