[
https://issues.jboss.org/browse/ISPN-1340?page=com.atlassian.jira.plugin....
]
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