[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-1340) ReadCommitted - commited Cache.remove is not visible to other transactions

[Manik Surtani (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627878#comment-12627878 ] 

Manik Surtani edited comment on ISPN-1340 at 9/12/11 12:06 PM:
---------------------------------------------------------------

Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that should be expected.  E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine.  What would be a real problem is if you end up with _weaker_ isolation.  

So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics.  This should be fine, since you should never write code to _expect_ a weaker isolation level.  Isolation levels are only configured to be weaker as a performance tradeoff.

In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation.  So the tradeoff isn't really worth it.

      was (Author: manik):
    Agreed, but this still should be acceptable since isolation levels are a _minimum_ level of isolation that should be expected.  E.g., if you configure *READ_COMMITTED* but end up with something closer to *REPEATABLE_READ* that is fine.  What would be a real problem is if you end up with _weaker_isolation.  

So in this case, you're saying when you configure *READ_COMMITTED*, you end up with seeing committed data most of the time, except when the data is concurrently removed, in which case you see *REPEATABLE_READ* semantics.  This should be fine, since you should never write code to _expect_ a weaker isolation level.  Isolation levels are only configured to be weaker as a performance tradeoff.

In this particular case, forcing Infinispan to give you strict *READ_COMMITTED* for deleted entries will result in a large performance penalty for what is weaker isolation.  So the tradeoff isn't really worth it.
  
> ReadCommitted - commited Cache.remove is not visible to other transactions
> --------------------------------------------------------------------------
>
>                 Key: ISPN-1340
>                 URL: https://issues.jboss.org/browse/ISPN-1340
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 5.0.0.FINAL
>         Environment: jboss-6.0.0.Final, isolationlevel=READ_COMMITED
>            Reporter: Marcel König
>            Assignee: Manik Surtani
>            Priority: Critical
>             Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL
>
>         Attachments: ReadCommittedLockTest.java
>
>
> See the attached unit test: i added the testVisibilityOfCommittedDataRemove method to your org.infinispan.api.mvcc.read_committed.ReadCommittedLockTest unit test class.
> This test is successful in infinispan-4.2.1 but not in infinispan-5.0.0.
> What happens:
> 1. transaction1(tx1): cache.put("k", "v")
> 2. tx2: cache.remove("k") 
> 3. tx2: commit
> 4. tx1: "v".equals(cache.get("k"))
> What should happen:
> ...
> 4. tx1: cache.get("k") == null

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira