On 18 Aug 2009, at 15:50, Galder Zamarreno wrote: > Hi all, > > More stuff related to the infinispan cache provider. The way we deal > with transactions that are not ACTIVE or PREPARING has changed from > JBoss Cache to Infinispan. > > In JBoss Cache, TransactionTable.getCurrentTransaction() logged a > message if the transaction's status was committed whereas Infinispan > simply throws an IllegalStateException if the status is neither ACTIVE > nor PREPARING. > > This change of behaivour is making Infinispan cache provider tests that > do bulk modifications to fail. The reason it fails is because Hibernate > has a javax.transaction.Synchronization implementation called > CacheSynchronization that in it's afterCompletion(), it leads to call > BulkOperationCleanupAction.evictEntityRegions() which clears the cache > for the affected entities. Now, since the tx status is COMMITTED, the > test fails. Surely though, at that stage the tx has already committed (and hence the name of the callback - afterCompletion()). If anything, operations here should happen outside the scope of the tx.

Can't the cleanup call happen in beforeCompletion(), after any Hibernate resources have performed their beforeCompletion() steps?

> Would there be any problems in maintaining the previous logic? While I don't have any problems reverting to the older logic, I just feel that doing so hides bugs elsewhere.

Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

> > >> Would there be any problems in maintaining the previous logic? > > While I don't have any problems reverting to the older logic, I just > feel that doing so hides bugs elsewhere. I agree but seeing that the logic was present in JBC, I assumed that this might have been discussed in the past.

On Tue, 2009-08-18 at 16:50 +0200, Galder Zamarreno wrote: > > This change of behaivour is making Infinispan cache provider tests that > do bulk modifications to fail. The reason it fails is because Hibernate > has a javax.transaction.Synchronization implementation called > CacheSynchronization that in it's afterCompletion(), it leads to call > BulkOperationCleanupAction.evictEntityRegions() which clears the cache > for the affected entities. Now, since the tx status is COMMITTED, the > test fails. This is no longer accurate. There was a bug in how BulkOperationCleanupAction worked because it was still using the older Hibrnate cache SPIs. See http://opensource.atlassian.com/projects/hibernate/browse/HHH-4034

Right, so basically it's time for me to integrate this into HB trunk. I'll start with that work asap. On 08/18/2009 08:36 PM, Steve Ebersole wrote: > To clarify further... > > Within txn here there are calls to: > 1) cacheAccess.lockRegion() > 2) cacheAccess.removeAll() > > In after-completion phase there is a call to: > 3) cacheAccess.unlockRegion(lock-from-#1) > > A transactional cache would not care about #1 nor #3... > > > On Tue, 2009-08-18 at 13:25 -0500, Steve Ebersole wrote: >> On Tue, 2009-08-18 at 16:50 +0200, Galder Zamarreno wrote: >>> This change of behaivour is making Infinispan cache provider >>> tests that >>> do bulk modifications to fail. The reason it fails is because >>> Hibernate >>> has a javax.transaction.Synchronization implementation called >>> CacheSynchronization that in it's afterCompletion(), it leads to >>> call >>> BulkOperationCleanupAction.evictEntityRegions() which clears the >>> cache >>> for the affected entities. Now, since the tx status is COMMITTED, >>> the >>> test fails. >> This is no longer accurate. There was a bug in how >> BulkOperationCleanupAction worked because it was still using the >> older >> Hibrnate cache SPIs. See >> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4034 >> >> -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

A FYI: Integrated with HB trunk and test now passes without any probs. Many thanks Steve! On 08/18/2009 10:57 PM, Manik Surtani wrote: > Great! > > On 18 Aug 2009, at 20:40, Galder Zamarreno wrote: > >> Right, so basically it's time for me to integrate this into HB >> trunk. >> I'll start with that work asap. >> >> On 08/18/2009 08:36 PM, Steve Ebersole wrote: >>> To clarify further... >>> >>> Within txn here there are calls to: >>> 1) cacheAccess.lockRegion() >>> 2) cacheAccess.removeAll() >>> >>> In after-completion phase there is a call to: >>> 3) cacheAccess.unlockRegion(lock-from-#1) >>> >>> A transactional cache would not care about #1 nor #3... >>> >>> >>> On Tue, 2009-08-18 at 13:25 -0500, Steve Ebersole wrote: >>>> On Tue, 2009-08-18 at 16:50 +0200, Galder Zamarreno wrote: >>>>> This change of behaivour is making Infinispan cache provider >>>>> tests >>>>> that >>>>> do bulk modifications to fail. The reason it fails is because >>>>> Hibernate >>>>> has a javax.transaction.Synchronization implementation called >>>>> CacheSynchronization that in it's afterCompletion(), it leads >>>>> to call >>>>> BulkOperationCleanupAction.evictEntityRegions() which clears >>>>> the cache >>>>> for the affected entities. Now, since the tx status is >>>>> COMMITTED, the >>>>> test fails. >>>> This is no longer accurate. There was a bug in how >>>> BulkOperationCleanupAction worked because it was still using the >>>> older >>>> Hibrnate cache SPIs. See >>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4034 >>>> >>>> >> >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache