[infinispan-dev] Implicit locking

[Manik Surtani]

On 25 May 2009, at 21:43, Vladimir Blagojevic wrote:

> On 5/25/09 9:02 PM, Manik Surtani wrote:
>>
>> I think putting this in the TxInterceptor makes sense since it only  
>> affects writes within a tx.  Perhaps subclassing the TxInterceptor  
>> to do this?
>>
> You mean make a sublclass and override enlistWriteAndInvokeNext to  
> do the similar plumbing but add eager locking? This can be done  
> easily. What do we do for clear and putAll commands? Locking  
> everything does not make that much sense for clear, does it? Not  
> sure. But what about putAll - lock all keys from the parameter map?

About clear, agreed.  No sense in eager locking for clear.  And for  
putAll, yes again - get all keys from the command.

>
>
>>> Another requirement is not to repeatedly send LCC command around  
>>> the cluster for write operation that already caused locks to be  
>>> obtained eagerly around the cluster. I think this requirement can  
>>> be handled within LockInterceptor#visitLockControlCommand thus  
>>> hiding the complexity away from possible invocation of  
>>> LockControlCommand from either CacheDelegate or TxInterceptor.
>>
>> Hmm, good point.  Maybe then it does make more sense to put it in  
>> the LockingInterceptor.
>>
> Not so much. It is easier to do it from TxInterceptor I think. In  
> overridden enlistWriteAndInvokeNext we create LCC instances and pass  
> the along the chain. We will slightly change  
> LockIterceptor#visitLockControlCommand to handle these specific  
> cases - not so hard.

Ok

>
>
>
> Cheers,
> Vladimir
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org