On Apr 28, 2013, at 7:08 PM, cotton-ben <ben.cotton(a)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/Infin...
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(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