On May 1, 2013, at 11:24 AM, cotton-ben <ben.cotton(a)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-JCac...
Sent from the Infinispan Developer List mailing list archive at
Nabble.com.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org