I am using EhCache's RMI synchronous replication to replicate the cache across 4 managed servers.
I am not able to solve how to handle following situation - suppose my node 1 has received an update (lets says google=$100) for an existing element (google) present in cache, so it updates the element in its server cache and starts replicating across node 2, 3 and 4. Now, before replication could start or reach at node 3, node 3 receives another update google=$103 for same element. So, node3 updates its server cache and starts replication across other nodes - node1, 2 and 4. Now, since EhCache uses read-write lock, so even if the replication started by node 1 (for google=$100) reaches node 3, it will wait for google=$103 update to complete at node3, and then google=$100 will be replicated at node 3.
So, essentially node 3 ended up with dirty update because latest value is google=$103 but it will hold google=$100.
My guess is that this issue will only be with node 3 (or any node which has received another update for same element before the last update could be replicated across all the nodes) because for node 2 and node 4, first google=$100 will be replicated and then google=$103 will be replicated so they will hold the latest value/update.
I read about BlockingCache and SelfPopulatingCache of EhCache but it doesn't solve this problem either.
Anybody any idea on this or faced this problem?