-
1. Re: Return value of Cache.remove(key) in transactional context
vblagojevic Jul 17, 2012 1:15 PM (in response to c_lohmn)Hi Carsten,
What type of transactions setup/locking do you use and which Infinispan release. I'll ping a colleague who is an expert in area of transactions to have a look.
Regards,
Vladimir
-
2. Re: Return value of Cache.remove(key) in transactional context
c_lohmn Jul 18, 2012 2:50 AM (in response to vblagojevic)Hi Vladimir,
I'm using Infinispan 5.1.5 FINAL. In our scenario, we are using transactions with LockingMode.PESSIMISTIC and locking with IsolationLevel.REPEATABLE_READ (or even SERIALIZABLE).
Easiest would be to look at DummyTxTest.
If "cache.remove(key)" is supposed to behave in the same way as "cache.remove(key, value)" (regarding its return value in case the key is actually removed), then this test should pass with "cache.remove("k1", "v1")" being replaced by "(cache.remove("k1") != null)".
But nonetheless it fails in that case.
Cheers,
Carsten
-
3. Re: Return value of Cache.remove(key) in transactional context
galder.zamarreno Jul 19, 2012 7:56 AM (in response to c_lohmn)@Carsten, that looks like a bug. Rather than trying to modify an existing test, you could try to add a new test method to DummyTxTest to verify this. The idea is that each test method can exercise different remove() calls. Currenlty we test the conditional remove(). Could you submit a bug in https://issues.jboss.org/browse/ISPN ?
-
4. Re: Return value of Cache.remove(key) in transactional context
c_lohmn Jul 19, 2012 6:44 PM (in response to galder.zamarreno)Galder Zamarreño wrote:
Rather than trying to modify an existing test, you could try to add a new test method to DummyTxTest to verify this. The idea is that each test method can exercise different remove() calls.
yes, sure. I just wanted to point to a quick way to reproduce the behaviour.
I've added ISPN-2164.