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-JCac...
Sent from the Infinispan Developer List mailing list archive at
Nabble.com.