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).
--
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