[infinispan-dev] SingleJoinTest#testTransactional failure

Mircea Markus mircea.markus at jboss.com
Tue Nov 30 20:16:11 EST 2010


On 30 Nov 2010, at 17:18, Vladimir Blagojevic wrote:

> On 10-11-30 1:51 PM, Mircea Markus wrote:
>>> I would love to but I do not see a method wrapEntryforWritingIfYouCan :-) What do you do in these kinds of situations? Set timeout to 10 msec and catch TimeoutException?
>> My point is you don't want to invalidate(invoke next) keys for which you don't have the locks. These would be invalidated(i.e. removed) at commit time.
>> 
> 
> Ok I get you! I think. So you would essentially simply do:
> 
>    if(!lockManager.isLocked(key)){
>        invokeNextInterceptor(ctx, commandToInvalidateKey(key));
>    }

> 
> But isn't this a race at least at some level between this thread which removes entries from a data container (without holding any locks) and another thread/tx which potentially locks the same keys only to find them removed from data container. Not sure, but this sounds a bit fishy!
Very fishy! this is exactly what I wanted to avoid. The previous code you sent:
>> public Object visitInvalidateCommand(InvocationContext ctx, InvalidateCommand command) throws Throwable {
>>     try {
>>        if (command.getKeys() != null) {
>>           for (Object key : command.getKeys()) {
>>              if(!lockManager.isLocked(key))
>>                  entryFactory.wrapEntryForWriting(ctx, key, false, true, false, false, false);
>>           }
>>        }
>>        return invokeNextInterceptor(ctx, command);
> 
In this code the call "invokeNextInterceptor(ctx, command);" will invalidate all the keys that are aggregated by InvalidateCommand _including_ the ones for which it couldn't acquire locks - bad! 
> 
> What do you think?
> 




More information about the infinispan-dev mailing list