[infinispan-dev] JCache implementation documentation

cotton-ben ben.cotton at ALUMNI.RUTGERS.EDU
Wed May 1 05:24:57 EDT 2013


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

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

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?

*





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


More information about the infinispan-dev mailing list