This post originated from an RSS feed registered with Java Buzz
by Talip Ozturk.
Original Post: JavaSpaces replication issues
Feed Title: Shared Memory
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: about java, jini, javaspaces, programming, aop and a little bit of me and life.
I have been thinking about JavaSpaces cluster implementation issues for
a while. I wanted to write them down and get peoples' opinions. Please
let me know if I am skipping something or you think there are other
issues to be considered. These are mainly replication issues.
1. asynchronous replication. Obviously asynch. replication will help
performance of an javaspaces impl. It is very good if the intent is to
back up the state of a space so that if master(original space) dies,
invocations can be routed to the replica. That means if A is the
original space and B is its replica then every invocation goes to A
until A dies. When it dies, invocations are routed to B. This is nice.
on the other hand, if A and B has no master-slave relation and both are
used for load balancing and replication then it is problematic to use
asynch. replication because let say you write an entry to A then load
balancer chooses B for the next invocation which is doing read
operation, client may not be able to read that entry from space B
because space A replicates the entries in asynch. fashion. In
conclusion, asynch. replication should not be used if replica is a part
of load-balance group in the cluster.
in short;
if (load-balance & asynchronous replication) throw new Exception ("subject to inconsistency" :)
this may not be correct if load-balancing policy is written to work with
asynch. replication scenarios. Round-robin will cause problem for
example.
2. Handling lease cancellations. Lets say space A and B are clustered
(load balance, fail-over, replication). You write entry E into the
cluster; load balancer chooses space A as target space, then entry E is
written to the space A and returns a lease to the client. Since A and B
are in replication group, the entry is replicated into space B
synchronously or asynchronously. Client that wrote the entry E into
clustered-space acquires the lease and before it expires, client
explicitly cancels the lease. Since the lease is issued by space A,
space A will remove the entry E. That should also result in removing the
entry E from space B.
Previous Topic
