[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1340) ReadCommittedLock - 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=12622172#comment-12622172 ] 

Manik Surtani commented on ISPN-1340:
-------------------------------------

I'm not entirely sure this is a bug.  In the context of tx1, a new entry is created or an existing one mutated when you do the PUT, so this mutation is stored in the transaction context and will be read again.  If you hadn't done a PUT but instead done a GET in tx1, then you would get the behaviour you expect.

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