Re: [infinispan-dev] Implicit locking

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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev