[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