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(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