Hi Rujith, Certainly this is a very interesting discussion and helping me a lot in understanding some of Axis2 internals.
Please find my comments below. Regards, Sanjaya On Wednesday 07 February 2007 03:53, Rajith Attapattu wrote: > > [RA] Yes, pessimistic locking is expensive and slow. If we really want to > do locking, then we should do optimistic locking (WADI supports this). But > for the first phase I would like to go without locking. Tomcat clustering > is built on Tribes and they have no distributed locking. As you correctly > pointed out the contexts are like the HTTPSession and shouldn't be abused > by the Web Service developer to shove anything and everything into it and > do frequent writes. This should be clearly stated in documentation. > > The expectation is to use some simple state (mostly read only with > intermittent writes), just like a HTTPSession. > > However there is a difference btw the HTTPSession case and the context case > that makes things a bit hard. With HTTPSession if we use session affinity > a.k.a sticky sessions then we make sure requests for the same session is > routed to the same node. So even w/o locking we can get rid of the > concurrency issues. The replication happens merely for failover. > > But with Axis2 (if HTTP is not used as transport) we cannot do session > afinity. So we might face concurrency issues. Unless we use Synapse as a > Load Balancer that knows the interpret the serviceGroupId as the session > key. [SK] So why not use Synapse? Of course there is an option of embedding a simple but a fast load balancer as the default load balancer. It is always good to have different configurations available for different requirements when it comes to application development. Only thing required is some good documentation. > > [RA] The only way to avoid dirty reads completly is to do pessimistic > locking :( > For now lets keep things simple. Later let us try to come up with a way to > layer some locking mechanism on top of the cluster impl. > [SK] Certainly, starting with small steps is always important and work. But let's have the discussion going so that we keep an eye on the final goal while doing that. Message ordering provided by the communication framework to work, it should be notified on all the dependant events. However there is a cost associate with this. The question is where do you invest? Which approach handle concurrency with the least cost? Let me explain how total ordering going to work. In total ordering message m+1 is delivered to all the recipients before message m is delivered. When event execution is synchronous, the event will be automatically blocked until the message is delivered. This way if a write happen at time t and if a read start concurrently at time t+1 the event will be automatically blocked until the write is delivered to all the recipients. Which event occurred first (happen before) can be determined using the Lamport algorithm. A relaxed approach is to use causal ordering of messages, if the causal order of events can be determined. There, events for which the order cannot be determined, is treated as independent and does not enforce any ordering. Sounds very expensive ha.... :-) But if you really look at it, locking techniques essentially does the same with giving you the additional overhead of tackling distributed deadlocks. > > [RA]Sorry for not being clear. What I meant was the decesion points to > replicate (the exact replication points) > may fall outside of the context heirachy. That's why I think we need the > ClusterManager (atleast for the time being). > For example update state. > We can do this on per updateBasis (we can have a event listener like u said > that creates event for an add/update/remove proeprty), > instead, it's easy to call updateState at the end of the invocation from > the engine or anywhere deem suitable and then figure out the net state > change and then replicate. So we need more flexibility than events. > Does that make sense ? > [SK] OK I think I got your point. But then it nullify the ability make use of the real power provided by the underneath messaging infrastructure. It will be only used as a multicasting channel and we have to come up with techniques to tackle every thing else. > [RA] If you look at HTTPSession, the service author have no way of saying > how or when to replicate. > If the service author calls abuses this privilege then we have a > performance issue on hand. > Also I am not sure how the above way will lead to less conflicts? Can u > explain more? > [SK] Well in a HTTPSession what you have is simply name value pairs and that's all. There is no hierarchy as such. Any way now understand that the context here is actually has some significant differences. I guess why it leads to conflicts must be clear to you by now with my previous comment. > > [RA] Sorry what I meant was the decesion to replicate or points of > replication can be anywhere within the system. > (Not the state, the state is only encapsulated inside the ctx heirachy). > [SK] Got it. > > [RA] I don't think it's a big problem with performance, but dims pointed > out other issues where byte code manipulation may create to other non > technical realted issues. > My point cuts are the replication points. AOP will allow me to intercept > these points in a non intrusive manner. > [SK] OK. > > [RA] I made mistake, Phlips confirmed that he hasn't implemented total > ordering. Even JGroups doesn't have it. > There is evs4j from Guglielmo Lichtner which claims total odering. The > others seem to have different levels of garuntees. > [SK] Have you checked Appia and stuffed developed at Cornell? As I told you we may get away with causal ordering too. > > [RA] It is simple, all you need to do is to add the following to your > axis2.xml > <cluster class="org.apache.axis2.cluster.tribes.ClusterManager" /> > > You can put any implementation that implements the ClusterManager > interface. > [SK] OK. Cool.
