Mohammad Nour El-Din wrote: > Just to make sure I am following this subject right. > > The client is going to have a servers list, and initially it will be > attached to a server, lets say the server which created this client > interface, and if for instance this server failed over the client is going > to use the next server in it current list which has a version VerX for > example, and while the client is contacting the other server sending it the > request with the its current version, the server will find out that the > version is not correct and it will respond to the client with the new > version. Did I understand the whole discussion right ?
Yep. Jeff > > > On 6/13/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> >> >> On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote: >> >> > Last time I helped with clustering (on another J2EE server), the >> > term thrown around was "cluster topology", which is not only the >> > membership of the server but the organization of the nodes in the >> > cluster. Over time servers join and leave the cluster and nodes >> > can be repurposed. After each mutation of the topology, the >> > version number would increment (or the hash changes). >> >> What would help to mitigate this issue would be to have some value >> that indicates a state change of the server and include this in the >> hash calculation. >> > > >
