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 ;-) > > 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 >>
