[infinispan-issues] [JBoss JIRA] Reopened: (ISPN-1340) ReadCommittedLock - commited Cache.remove is not visible to other transactions
[
https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin....
]
Marcel König reopened ISPN-1340:
--------------------------------
Sorry, I think I made a mistake in describing the problem. The first put should be
commited.
Please see the unit test.
In the Unit Test:
1. cache.put("k","v")
2. tx1 begin + cache.get("k") == "v"
3. tx2 begin + cache.remove("k")
4. tx1 cache.get("k") == "v"
5. tx2 commit
6. tx1 cache.get("k") == "v" but should be null
In our application we do the first put in an own sub transaction (REQUIRES_NEW) of tx1 so
that the put should be commited. Perhaps I should change the unit test to do the put in an
own transaction like tx0.
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