[infinispan-dev] JCache implementation documentation

[Galder Zamarreño]

On Apr 28, 2013, at 7:08 PM, cotton-ben <ben.cotton at ALUMNI.RUTGERS.EDU> wrote:

> Hi Galder,
> 
> Thanks for your off-line email exchange confirming that community
> contributed tests of 5.3.0A's JSR-107 transactions option capability (and
> compliance) are welcome.
> 
> Here is what we would like to contribute initially.
> 
> 1.  A test that 5.3.0.A can (both optimistically and pessimistically)
> accommodate a DIRTY_READ intolerant use-case via the JSR-107 API.  Attached
> is sample JSR-107 PSEUDO code to drive this test (PESSIMISTIC policy).
> 
> 2.  A test that 5.3.0.A can accommodate a REPEATABLE_READ mandatory 
> use-case via the JSR-107 API.  (TODO=code).
> 
> 3.  A test that 5.3.0.A can accommodate a PHANTOM_READ intolerant use-case
> via the JSR-107 API.  (TODO=note it is KNOWN that 5.3.0.A cannot yet
> accommodate this use case as TotalOrder on Infinispan does not yet provide
> isolation=SERIALIZABLE implementation.  However, to be compliant with the
> JSR-107 Transactions option, an implementation must provide all isolation
> levels)
> 
> 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.

> 
> 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 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