Sorry for the late response. Currently there is no locking. This is kind of expensive to implement too. Another reason is I couldn't find a framework that supports this. WADI has this support, but currently it is difficult to adapt it to the context replication problem.
As Sanjaya mentioned, sticky session is the way to go. This is simple but only solves part of the problem. This will only help for services deployed in scope "soap session" with a single client. For services that has application scope and for service group ctx this will not work. There can be two clients that wants to modify the same state which will cause the problems described by Azeez. The current clustering solution is best used as a failover strategy in a primary/backup(s) situation. If you want more than one active node for a particular service then u need to use sticky sessions and avoid putting state in service group contexts that can be modifiable (Also avoid using services with application scope). In others words state in a service group ctx should be read only for most part or else your services will have inconsistent states. If u have more than 2 nodes try to partition your services among the nodes and pair them up as primary/backup(s) instead of having more than one active node. ex. If u have 10 nodes and 5 services then a simple solution maybe to make 5 pairs with each service being deployed in primary/backup mode. More elaborate configurations can designate more than one backup. However the trick is to have only one active node per service. Regards, Rajith Btw, we need to clearly document our clustering support, highlighting the limitations and capabilities. On 5/19/07, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote:
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]
