[hibernate-dev] [infinispan-dev] [ISPN-6] COMMITTED tx status handling changed from JBC to ISPN
Galder Zamarreno
galder.zamarreno at redhat.com
Tue Aug 18 11:30:32 EDT 2009
On 08/18/2009 05:21 PM, Galder Zamarreno wrote:
>
> 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.
Searched through the call hierarchy and there're calls to evictAll
coming from BulkOperationCleanupAction.init() and these don't seem to
come from afterCompletion() stages, so don't think I can make the
suggested assumption above.
>
> 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
More information about the hibernate-dev
mailing list