This content has been marked as final.
Show 4 replies
-
1. Re: Possible bug with putForExternalRead in 3.0.1
manik Dec 9, 2008 12:56 PM (in response to soee)Back to my old mantra - have you got a unit test for this? :-) It should be easy enough to write one and test whether pFER() waits for locks - have a tx acquire the lock and then suspend the tx, then try the pFER().
Disabling lock acquisition does not happen in the CacheInvocationDelegate, but in the locking interceptor instead. e.g. PessimisticLockInterceptor:@Override protected Object handlePutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable { return handlePutCommand(ctx, command, false); } @Override protected Object handlePutForExternalReadCommand(InvocationContext ctx, PutForExternalReadCommand command) throws Throwable { return handlePutCommand(ctx, command, true); } private Object handlePutCommand(InvocationContext ctx, DataCommand command, boolean zeroAcquisitionTimeout) throws Throwable { .... }
You are right though that this seems to have been missed out in the MVCCLockingInterceptor.
Could you confirm that you saw this problem with MVCC and not PL/OL? -
2. Re: Possible bug with putForExternalRead in 3.0.1
manik Dec 9, 2008 1:02 PM (in response to soee)Just raised a JIRA for this JBCACHE-1450.
-
3. Re: Possible bug with putForExternalRead in 3.0.1
soee Dec 9, 2008 2:25 PM (in response to soee)Sorry for the missing test case :)
But yes, it was with MVCC locking (did not try Pessimistic or Optimistic). -
4. Re: Possible bug with putForExternalRead in 3.0.1
soee Dec 9, 2008 2:26 PM (in response to soee)Already fixed on HEAD i can see.. Thanks !