Re: [infinispan-dev] SingleJoinTest#testTransactional failure

On 30 Nov 2010, at 16:51, Mircea Markus wrote: > > On 30 Nov 2010, at 16:42, Vladimir Blagojevic wrote: > >> On 10-11-30 1:35 PM, Mircea Markus wrote: >>> On 30 Nov 2010, at 14:30, Vladimir Blagojevic wrote: >>> >>>> On 10-11-30 10:49 AM, Vladimir Blagojevic wrote: >>>>> I like your solution. It seems to be less disruptive to ongoing >>>>> transactions then the other two solutions. >>>>> >>>>> How would you safely detect that K is locked by another tx and thus skip >>>>> locking? >>>> I do *not* think I can do the following in LockingInterceptor: >>>> >>>> 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); >>> Perhaps you only want to run invokeNext for the keys for which you acquired locks? >> >> 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. Right, provided the tx knows to invalidate these keys at commit (or rollback). Right?

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev