Locking is going to make the system highly inefficient. There are not many systems in production which do this. e.g. In Tomcat, the default behavior is to fire & forget (ASYNC) mode of transmitting state info. In Axis2, we support both SYNC_ACK & ASYNC depending on the level of accuracy you need and the response time. The replication takes just a few milliseconds. In caching & throttling, I believe we only replicate the changes and not the entire map, in which case most of these complications will not exist.
Azeez On Wed, Jan 30, 2008 at 12:35 AM, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > On Jan 29, 2008 1:13 PM, Ruwan Linton <[EMAIL PROTECTED]> wrote: > > > Rajith, > > > > > > > > > > > > Most part of synapse is stateless and hence does not have any effect > > > > over clustering, but Caching and Throttling does. So Caching and > > > > Throttle > > > > mediators use the axis2-clustering implementation to replicate the > > > > state of > > > > those mediators among the cluster within the implementation of those > > > > mediators it self. Other than that we do not replicate states of > > > > synapse in > > > > a global scope. I think this model fits for the moment and has > > > > performance > > > > improvements over supporting clustering in a global scope. > > > > > > > > > > Yep I am in agreement. The reason I asked about clustering is bcos of > > > the recent thread on session mgt and the need to have the session-mediator > > > state replicated across the cluster (I hope I didn't misunderstand the > > > requirments here). I was wondering if this sort of thing is trivial to > > > implement. Like can we replicate any mediator state if we choose to in a > > > trivial way? > > > > > > > Yes it is, I think the session-mediator has to take the replication in > > to account (i.e. another state full mediator for synapse :)). If you are > > using the ConfigurationContext of axis2 (basically the whole context > > hierarchy) to store the data (for example, the session data table mapped > > using a session id) ** you just need to call ConfigurationContext.flush(); > > to replicate any data which has been changed after the last replication. > > Additionally if you need to just replicate some of the properties of the > > cfgCtx then you can call the the flush method with the property names (see > > the clustering API for the exact signature of the method, I don't remember > > that exactly). > > > > Ruwan, once again thank you for the detailed answer. I really appreciate > it. The reason behind the question "can we replicate any mediator state if > we choose to in a trivial way?" was to figure out if the current axis2 > clustering support is sufficient. > > However we have to be careful when replicating mediator state especially > when there are concurrent modifications on different nodes. This can cause > undesired affects and it is a limitation in our current clustering > implementation. So even for the session map, if two nodes modify the map > concurrently we may have issues. This doc explains the limitations > http://ws.apache.org/axis2/1_3/clustering-guide.html. > So perhaps it's worthwhile to highlight these issues to synapse users who > want to tap into the clustering support. > > thanks, > > Rajith Attapattu > Red Hat > blog: http://rajith.2rlabs.com/ > > > > Or else to replicate the whole context hierarchy you could use > > Replicator.replicate(); as well. One has to decide the proper method and > > when to use which by evaluating the complexity and performance of the > > implementation .... > > > > Thanks, > > Ruwan > > > > -- > > Ruwan Linton > > http://www.wso2.org - "Oxygenating the Web Services Platform" > > > > > -- Thanks Afkham Azeez http://azeez78.blogspot.com http://www.wso2.org GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
