Please consider taking a look at the attached plan for Test #1.
It is very simple. A "Savings Account" is cached in Infinispan 5.3.0.A.
Two transactional threads simultaneously operate (access/mutate) on the
"Savings Account". Transactional Thread #2 indicates via the JSR-107 API
that is is "DIRTY_READ" intolerant (by specifying
isolation=READ_COMMITTED).
It expects a pessimistic locking policy to be used by 5.3.0.A (i.e. to
block
@t=2 on its READ invoke). Therefore a challenge to 5.3.0.A's capability
is
to demonstrate the Thread 2 blocks @t=2. This test passes if Thread 2
blocks @t=2)
/^ Why should there be a block? Infinispan has non-blocking reads (which IMO
is better than blocking).
At t=2 with Infinsispan, TX_THR_2 will find the credit that was in the
account before TX_THR_1 did any modifications, whatever that is.
/
*Definitely non-blocking read capability is preferred! The problem is that
if TX_THR_2 does *any* read at t=2, it will then be reading UNCOMMITTED
data. In the Test, TX_THR_2 explicitly specified through JCACHE API that it
wants isolation=READ_COMMITTED ... and .. it thus expects that Infinispan
will honor that isolation choice (chosen because TX_THR_2 is "DIRTY READ"
intolerant) by blocking its read attempt at t=2. 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! The
context of TX_THR_2 is thus physically inconsistent. The bank's data is
corrupt.*
If you confirm this test is helpful, we will then provide a
policy=OPTIMISTIC test for #1. Later, at the appropriate time, we would
like to produce explicit tests for #2 and #3.
Infinispan-5.3.0.A1=JSR-107_TRANSACTIONS_OPTION=DIRTY_READ_INTOLERANCE_TEST.pdf
<http://infinispan-developer-list.980875.n3.nabble.com/file/n4026915/Infinispan-5.3.0.A1%3DJSR-107_TRANSACTIONS_OPTION%3DDIRTY_READ_INTOLERANCE_TEST.pdf>
Thanks,
Ben
--
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@.jboss
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder ZamarreƱo
galder@
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev@.jboss
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
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.