[infinispan-dev] JCache implementation documentation

[Galder Zamarreño]

On May 1, 2013, at 11:24 AM, cotton-ben <ben.cotton at ALUMNI.RUTGERS.EDU> wrote:

>> Failure to block that @t=2 
>> access to the un-committed CREDIT has dire-consequences ... e.g. if
>> TX_THR_1 
>> executes rollback() on  the credit @t=1 !  OUCH.  If Infinispan does not 
>> block TX_THR_2 read @t=2 then it proceeds as if the credit happened!   
> 
> /^ No, if it doesn't block, it reads whatever the last balance was, before
> TX_THR_1 started doing anything. 
> /
> 
> *Ah, I see now.  When TX_THR_2 reads the last COMMITTED value ($5), and
> altogether ignores reading TX_THR_2's UNCOMMITTED value ($6), we agree that
> Infinispan is indeed exhibiting a valid implementation of a PESSIMISTIC
> policy for accommodating a DIRTY_READ intolerant use case.*

Underneath the covers it's mimicking MVCC behaviour. When T1 (typed more easily…) writes the value, it writes it in a copy of the value so that other threads can still read the original value.

> 
>> The 
>> context of TX_THR_2 is thus physically inconsistent.  The bank's data is 
>> corrupt.* 
> 
> /^ I see no corruption :) /
> 
> *You are correct, the non-locking Infinispan PESSIMISTIC policy you describe
> above is 100% valid and does not corrupt.  Thank you for your patience,
> Galder, to explain this.  I was thinking of a locked based approach to a
> PESSIMISTIC implementation (also valid), but the Infinispan approach
> described here is fine (and, for many use cases, preferred).

^ No worries :)

> 
> In a separate dev-list post, I provided a JSR-107 pessimistic test (that I
> could not get to run w/ Infinispan 5.3.0.a1's JCACHE 0.4 implemenation).  I
> see now that Infinispan will pass this test.
> 
> QUESTION:  Is there a native-Infinispan config to indicate an OPTIMISTIC
> policy (btw, this is not yet provided for via JSR-107 API) ?  I.e.  does
> Infinispan allow an OPTIMISTIC READ_COMMITTED isolation config that would
> result in the capability for TX_THR_2 to physically read the un-committed
> value @t=2 ($6) but would not allow TX_THR_2 to commit its transaction
> unless TX_THR_1 had already committed its @t=1 mutation?

We do indeed support optimistic locking within Infinispan: <LINK>

But, it won't work the way you mention. T2 won't read the un-committed value that T1 updated. T2 will read the last committed value, work with it, and when the transaction commits, it will fail because since the start of the transaction, T1 has modified the entry, and hence, the value T2 was operating on was outdated.

Cheers,

> 
> *
> 
> 
> 
> 
> 
> --
> View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-JCache-implementation-documentation-tp4026877p4026954.html
> Sent from the Infinispan Developer List mailing list archive at Nabble.com.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org