On Jun 12, 2007, at 10:23 AM, Jeff Genender wrote:
Matt Hogstrom wrote:
Wouldn't the server's themselves be operating off of some version
number
so they can synchronize their own state?
It would seem that this would be the same version number.
Yeah...actually a hash of the server list seemed to be a way to
calculate a version number across servers, so its in-sync based on the
cluster state. But Mr Blevins talked me out of this ;-)
I guess we never really talked about how each server would get the
list of peers in the cluster. Depending on how we do that, we could
return to the md5'ed list idea but not the way it was proposed where
the hash would be calculated by both sides on every request -- at
least that's the way i read it.
-David
On Jun 11, 2007, at 5:04 PM, Jeff Genender wrote:
Ok...so now that we have passed the TCK...I can get back and
concentrate
on some fun stuff, so I wanted to bring up the old discussion
again of
getting a clustering API pinned up on OpenEJB. The whole idea on
this
is to allow different clustering components to tie into the product.
Before I stopped and did TCK testing, I got as far as adding the
ability
to handle multiple URLs in the client/server to allow for failover.
Now that I am getting back to the meat of the design here, I
wanted to
go over at a high level of the direction I am taking this.
1) The client need to get an initial list of servers in the
cluster. I
assume this can occur during the first initial context handshake.
2) A version number is applied and sent along with the list.
3) Every time the client speaks to the server is sends along the
version
number. If the version is different, the server sends down a new
list,
along with the new version number.
4) The server updates the list only when the servers in the
cluster have
changed.
Thoughts and comments?
Jeff
