[infinispan-dev] JCache implementation documentation

[Galder Zamarreño]

On Apr 29, 2013, at 1:28 PM, cotton-ben <ben.cotton at 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
>> &lt;http://infinispan-developer-list.980875.n3.nabble.com/file/n4026915/Infinispan-5.3.0.A1%3DJSR-107_TRANSACTIONS_OPTION%3DDIRTY_READ_INTOLERANCE_TEST.pdf&gt;  
>> 
>> 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 at .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 at .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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org