[infinispan-issues] [JBoss JIRA] (ISPN-4910) Document inconsistent behavior of ReadCommitted isolation level in some scenarios

[Martin Gencur (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gencur updated ISPN-4910:
--------------------------------
    Description: 
Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html:
{code:java}
public void testSizeWithPreviousRead() throws Exception {
      tm(0).begin();
      cache(0).put(k0, "v0");
      cache(0).put(k1, "v1");
      assertEquals(2, cache(0).size());
      tm(0).commit();

      tm(0).begin();
      //make sure we read k1 in this transaction
      assertEquals("v1", cache(0).get(k1));
      final Transaction tx1 = tm(0).suspend();

      //another tx working on the same keys
      tm(0).begin();
      //remove the key that was previously read in another tx
      cache(0).remove(k1);
      cache(0).put(k0, "v2");
      tm(0).commit();

      tm(0).resume(tx1);
      //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account
      assertEquals(1, cache(0).size());
//^^^^^  the test fails here, cache.size() return 2 instead of expected 1
      assertEquals("v2", cache(0).get(k0));
      assertNull(cache(0).get(k1));
      tm(0).commit();

      assertNull(cache(1).get(k1));
   }
{code}

I will add tests as part of ISPN-4820 to show the behavior, we just need to document it.

  was:
Document the following (incorrect and unexpected) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html:
{code:java}
public void testSizeWithPreviousRead() throws Exception {
      tm(0).begin();
      cache(0).put(k0, "v0");
      cache(0).put(k1, "v1");
      assertEquals(2, cache(0).size());
      tm(0).commit();

      tm(0).begin();
      //make sure we read k1 in this transaction
      assertEquals("v1", cache(0).get(k1));
      final Transaction tx1 = tm(0).suspend();

      //another tx working on the same keys
      tm(0).begin();
      //remove the key that was previously read in another tx
      cache(0).remove(k1);
      cache(0).put(k0, "v2");
      tm(0).commit();

      tm(0).resume(tx1);
      //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account
      assertEquals(1, cache(0).size());
//^^^^^  the test fails here, cache.size() return 2 instead of expected 1
      assertEquals("v2", cache(0).get(k0));
      assertNull(cache(0).get(k1));
      tm(0).commit();

      assertNull(cache(1).get(k1));
   }
{code}

I will add tests as part of ISPN-4820 to show the behavior, we just need to document it.



> Document inconsistent behavior of ReadCommitted isolation level in some scenarios
> ---------------------------------------------------------------------------------
>
>                 Key: ISPN-4910
>                 URL: https://issues.jboss.org/browse/ISPN-4910
>             Project: Infinispan
>          Issue Type: Task
>          Components: Documentation-Core
>    Affects Versions: 7.0.0.CR2
>            Reporter: Martin Gencur
>
> Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html:
> {code:java}
> public void testSizeWithPreviousRead() throws Exception {
>       tm(0).begin();
>       cache(0).put(k0, "v0");
>       cache(0).put(k1, "v1");
>       assertEquals(2, cache(0).size());
>       tm(0).commit();
>       tm(0).begin();
>       //make sure we read k1 in this transaction
>       assertEquals("v1", cache(0).get(k1));
>       final Transaction tx1 = tm(0).suspend();
>       //another tx working on the same keys
>       tm(0).begin();
>       //remove the key that was previously read in another tx
>       cache(0).remove(k1);
>       cache(0).put(k0, "v2");
>       tm(0).commit();
>       tm(0).resume(tx1);
>       //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account
>       assertEquals(1, cache(0).size());
> //^^^^^  the test fails here, cache.size() return 2 instead of expected 1
>       assertEquals("v2", cache(0).get(k0));
>       assertNull(cache(0).get(k1));
>       tm(0).commit();
>       assertNull(cache(1).get(k1));
>    }
> {code}
> I will add tests as part of ISPN-4820 to show the behavior, we just need to document it.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)