On Apr 29, 2013, at 1:28 PM, cotton-ben <ben.cot...@alumni.rutgers.edu> wrote:
>> >> 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. ^ I disagree. With non-blocking read capability, TX_THR_2 will read the last committed value assigned to that key, before TX_THR_1 started doing anything, whatever that is... > 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. ^ Again, I don't see where READ_COMMITTED orders for any blocking to happen. It expects the last committed value to be read. > 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. > The > context of TX_THR_2 is thus physically inconsistent. The bank's data is > corrupt.* ^ I see no corruption :) > >> >> 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-JCache-implementation-documentation-tp4026877p4026915.html >> 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-JCache-implementation-documentation-tp4026877p4026927.html > Sent from the Infinispan Developer List mailing list archive at Nabble.com. > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev