[infinispan-dev] Implicit locking

[Vladimir Blagojevic]

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?

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


Cheers,
Vladimir