[hibernate-dev] [infinispan-dev] [ISPN-6] COMMITTED tx status handling changed from JBC to ISPN

[Galder Zamarreno]

On 08/18/2009 05:08 PM, Manik Surtani wrote:
>
> 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.

The cache provider integration layer does not know that the call to 
EntityRegionAccessStrategy.evictAll() is coming from an 
afterCompletion() call.

I don't know whether it can be assumed that calls to evictAll() always 
come from afterCompletion() stages and hence, I can suspend the tx in 
every evictAll() call.

Hibernate gang should be able to help with this.

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

I have no clue whether this is possible. Again, Hibernate guys, can you 
answer this?

>
>> 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.

>
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache