[infinispan-dev] SingleJoinTest#testTransactional failure

[Mircea Markus]

On 1 Dec 2010, at 11:24, Manik Surtani wrote:

> 
> On 1 Dec 2010, at 01:17, Mircea Markus wrote:
> 
>> 
>> On 30 Nov 2010, at 17:25, Manik Surtani wrote:
>> 
>>> 
>>> On 30 Nov 2010, at 17:08, Mircea Markus wrote:
>>> 
>>>> 
>>>> 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. 
>>> 
>>> Not unless L1 is enabled and you *want* the entry in L1 there.
>> even if the entry is removed from L1 this is not incorrect (at most sub-optimal).
> 
> Of course, but you can't expect *every* transaction to *always* remove entries it touches from L1.  This completely defeats the purpose of L1.
It won't *always* remove them. It would *only* remove entries if it is remote, owns locks on these entries and these entries do not belong to that node according to CH. 
> 
> The transaction needs to be made aware that some of the keys it touched has been exposed to rehashing and hence should be removed from L1 when the tx completes.  I don't think this is hard to do: what we'd need is:
> 
> * A subclass of the TxInvocationContext (DistributedTxInvocationContext?) which maintains a set of keys potentially rehashed
> * An L1InvalidationCommand would try and invalidate a key.  If it is unable to lock this key _and_ the lock is held by a transaction, add the key to the given transaction's context's potentially rehashed key set
> * When the transaction completes, it invalidates any keys before releasing locks.
> 
> WDYT?
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev