[infinispan-dev] [infinispan-internal] PutMapCommand is ineffective

Mircea Markus mmarkus at redhat.com
Tue Jul 9 05:45:15 EDT 2013


On 10 Jun 2013, at 17:30, Dan Berindei <dan.berindei at gmail.com> wrote:

> Yes, putAll is really heavy in non-tx (concurrent) mode, because the same PutMapCommand is forwarded from each primary owner to all the backup owners of the keys it primary-owns. However, I don't think 
> 
> However, in non-tx mode locks are owned by threads. A separate lock command would acquire a lock and associate it with its execution thread, making it impossible for a following write command to use the same lock. Changing putAll to implement Radim's proposal would indeed make it very similar to a transactional putAll: you'd need a pseudo-transaction object to associate the locks with, and a reaper to clean up the pseudo-transaction objects when the originator leaves the cluster.

Indeed would require some significant changes as we'd need to support lock to command association for non-tx caches. We could use some generated UUID for managing the lock owner in this case, or even an GlobalTransaction object.  

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list