[infinispan-dev] Non-tx X-Site: doubts and opinions

[Mircea Markus]

On Jan 8, 2014, at 11:36 AM, Pedro Ruivo <pedro at infinispan.org> wrote:

> Hi guys,
> 
> I'm digging in detail in X-Site code and I have a couple of 
> doubts/comments.
> 
> *Note*: I'm talking about non-tx caches :)
> 
> First, I've noticed that we are forcing the /site_master/ node to have a 
> reference to the cache in order to perform the modifications from other 
> sites. IMO, it can be possible the user may not want to have that cache 
> running that node. WDYT?
> 
> My idea is, if the /site_master/ has the reference to the cache, it can 
> use, otherwise it multicast the command to all the nodes in the site. 
> The nodes that does not have the cache (or if they are not primary owner 
> of any key) will ignore the command :)

Alternatively it could configure a capacityFactor==0 for that node and have the same effect.
Your approach is nice, but a bit more complex to implement IMO than the capacityFactor solution. 

> 
> Second and finally, I find a couple of optimization that can be done. #1 
> I've noticed that we are sending the conditional commands to the backup 
> sites without checking if the command is successful in the originator 
> site. I think we can save network bandwidth and time to avoid 
> serializing the commands that will fail...

+1

> 
> #2 Also, the originator is the node that sends the command to the other 
> sites. IMO, it can generate inconsistencies because 2 or more nodes in 
> /site_a/ can update the same key concurrently and other /site_b/ can 
> receive the commands in different order (at least, I didn't see any 
> protection mechanism against this case)
> I think the backup to other sites should be sent by the /primary_owner/ 
> (lock owner).

Good point.

> 
> Thanks in advance for the feedback.
> 
> Cheers and Happy New Year :)

Happy New Year! :-)

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

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