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?