Colocation of client and key owner for writes

Question

Hi,
In a distributed, replicated cache (1 backup copy) does the write to the backup owner for the key happen in parallel with the write to the primary owner? Or does the primary owner issue a synchronous update to the backup owner for the key? Other?
We are considering routing HTTP requests to the primary owner of a key to keep the primary update local and therefore only incur latency for the synchronous write to the backup owner. Would we see any benefit from doing this?
We do realize that primary owners can move with removal and/or addition of nodes and only see this as an optimization, not a requirement.
We are using Coherence version 3.3.
Thanks.

Answer 1

Bob,
>
>
I don't think you provided all relevantinformation
about this. What key and data are we speakingabout?
What would do the directing of the http request? The key and data are arbitrary, but it could be a set
of keys assigned to the same partition (using
Partition Affinity) that collectively represent a
session. The request would be directed by a network
device (e.g. F5).
What you outline here depends on and assumes a couple of things:
1. The load-balancer is aware of key ownership in a partitioned cache service and also does failover based on this. I am not sure if any hardware load-balancer is capable of doing that. Also, in that case the load-balancer would need an additional Coherence licence.
2. The load-balancer is able to translate or extract the key data from the HTTP request / its observations of the previous requests in the HTTP session. Again, I find it unlikely, but a little bit more doable.
3. As you say that the load-balancer directs the request to the specific node owning the key, that would mean that your Webapp nodes and only they would be the storage-enabled nodes for the data you refer on.
This (among others) means
- that you won't be able to bring down the JVM of the web containers without losing access to the cached data.
- your Coherence nodes has to be running inside the web container JVMs which possibly means additional licence costs (for other software in the web container) if the web container is not free
Even if there are such load-balancers (are there any?), are you sure you really want to do the things outlined above?
I think it is much more sensible to have a web container tier which has nothing to do with Coherence, and this way the load-balancer does not have to be Coherence-aware, and it allows you to be more flexible in the system architecture and the Coherence features you use, and not be constrained by what the load-balancer's Coherence features (if such a load-balancer exists at all) direct you to.
In a partitioned cache service (distributed ornear
cache) the write is always communicated to theowner
of the primary copy of the partition containingthe
relevant key, and that node communicates thechange
to all backups. This is done synchronously fromthe
client's viewpoint, meaning that this is allcarried
out before the put method call returns on the
client.From your reply, I believe we would be reducing
latency on our updates by routing the requests to the
node with the partitioned which owns the set of keys.It theoretically would, however I am not really sure that it is possible to do that from a load-balancer, and if it is worth doing that at all.
Are we really speaking about HTTP requests?
BR,
Robert