[infinispan-dev] Versioning wo/ transactions

Galder Zamarreño galder at redhat.com
Mon Dec 12 06:16:18 EST 2011


On Dec 9, 2011, at 4:51 PM, Manik Surtani wrote:

> 
> On 6 Dec 2011, at 11:46, Galder Zamarreño wrote:
> 
>> Hi,
>> 
>> Re: https://github.com/infinispan/infinispan/pull/697#r272846
>> 
>> When in place, I'd like to use the ability to provide a version externally with Hibernate in order get versions to come from Hibernate.
>> 
>> As indicated by http://community.jboss.org/wiki/VersioningDesignDocument, this would enable other Hibernate Cache concurrency strategies to be supported which are not necessarily transactional/
>> 
>> So, opening the debate, would it make sense for versioning to work also with non transactional environments? 
> 
> Well, in a non-transactional environment, is there any meaning in maintaining versions?  What happens when a put() fails?  How to you ensure the database write isn't then carried out?

The put call comes from Hibernate, so Hibernate needs to deal with it somehow, otherwise how is it gonna deal with read/write and nonstrict read/write cache concurrency modes?

If we take the case of inserting an entity (as opposed to reading a entity from db and putting it in the cache), Hibernate provides with two callbacks:

EntityRegionAccessStrategy.insert and EntityRegionAccessStrategy.afterInsert

The first call happens within the Hibernate transaction, and the second after the Hibernate transaction has completed.

If the cache is transactional, like Infinispan is now, it's at insert time that we do the cache.put call so we participate of the transaction…etc.

If the cache is read/write or non-strict read/write, you do nothing at insert time cos the cache is not transactional. Instead, you do the work in afterInsert. If there's any exceptions at afterInsert, it doesn't really matter because the transaction is complete and even if the cache.put() didn't work, the entity can get loaded next time around via a PFER into the cache.

With an entity update however, I don't see Hibernate doing anything if the equivalent afterUpdate() call throws an exception. It only seems to log it. This could lead to the cache containing stale data and being retrieved by mistake by another tx unless the cache is cleared upon a failure to in afterUpdate().

> 
> - M
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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




More information about the infinispan-dev mailing list