On Saturday 19 May 2007 14:57, Sanjaya Karunasena wrote: > On Saturday 19 May 2007 14:51, Sanjaya Karunasena wrote: > > On Saturday 19 May 2007 12:19, Afkham Azeez wrote: > > > Scenario: > > > > > > There are 2 nodes, N1 & N2 in a cluster. The 1st request from Client C1 > > > goes to N1. There is a state change in N1 due to this request. Before > > > the state is replicated to N2, C1 sends another request which goes to > > > N2. The result C1 gets is incorrect since N2 was in the old state. > > > > > > This happened to me when I ran two nodes on the same machine, and the > > > client was also on the same machine. Can such a scenario take place in > > > a production environment? > > > > > > Any idea how such a scenario can be handled? How do other clustering > > > implementations handle such a scenario? > > > > This is deffinitely a valid & frequent scenario in a prodcution > > environment. > > > > This is in the class of the session replication problem which requires > > some type of a transaction handling (Locking & roleback). > > > > Do we have such capabilities in the Axis2 clustering implementation? > > > > /Sanjaya > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > BTW, if this is the same client and there is no scenario as two clients > updating the same attribute concurrently, then a sticky session > configuration should solve the problem. > > /Sanjaya > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
Add to the same, if we are not supporting failover this would work. If we are to support failover, it should be some master slave scenario to keep things at a simple scalable level. /Sanjaya --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
