Re: [infinispan-dev] SingleJoinTest#testTransactional failure

On 30 Nov 2010, at 17:03, Manik Surtani wrote: > > 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? At commit/rollback, the tx can iterate over they keys involved (ones brought here by prepare): if the key is no longer mapped to this node then simply remove it; otherwise apply the change.