Hi Rajith, Please find my comments below marked with [SK]
Thanks Sanjaya On Monday 05 February 2007 20:28, Rajith Attapattu wrote: > Hello Sanjaya, > > comments are inline marked with [RA] > > Rajith Attapattu > Red Hat. > > > In a distributed scenario having the ability to handle concurrency is very > > > important. How do you tackle conflicting updates? There should be a way > > to rollback/commit. In otherwords the interface should be > > transactionable. Also > > having the ability to distinguish between read-only vs read/write access > > to > > the context is an opportunity to apply some optimizations to the actual > > implementation. > > [RA] This is where locking comes into picture. There are 2 different types > of locking mechanisms, pesimistic locking and optimistic locking. > Most databases use pesimistic locking and is expensive and slow, while > optimistic locking is relatively cheap. Negotiating concurrency issues is > best handled by the underlying infrastructure. Apache Tribes (the impl I > used and is using total ordering) and Richochet (garuntees are lower than > VS) are both low level reliable multicasting infrastructure and have no > support for locking. > WADI from codehaus specializes in locking. But for now we decided sometime > back to go without any locking for the following reasons. > > WADI is written for session replication and is difficult to adapt as is to > the context replication scenario we have with out some modifications. > Sanjiva and I debated on this issue for a while and agreed that we live > with the concurrency issues for the time being. > What we can do is to try to utilise WADI to provide locking support for our > implementation as the second step. [SK] Locking, which comes under pessimistic concurrency control is good for databases due to the high probability of conflicts. Optimistic concurrency work best when there are high number of reads with intermittent writes. But which way to go depends on what do we expect in the context. We can put some constrains or let the end user to configure it. But I don't think this is a good place to over engineer things. We should keep this very simple. I guess this is similar to the HTTPSession. We don't expect application developers to use the HTTPSession as their in memory database. Am I right? > > Detecting conflicts and rolling back is best decided at the infrastructure > level (for example WADI) rather than at the application level. > The logic for rolling back is complicated and if a rollback occurs we need > to notify the web service client. Currently there is no standard WS way of > doing that. > (Not sure WS-Context has anything regarding this) > > We can have dirty reads (cheap) and do locking only for updates. But ymmv. [SK] From the application developer point of view Axis2 itself is infrastructure. Obviously we should not pull him in to the picture. However application code which implements a refine requirement can provide some hints (like whether its OK to have dirty reads). > > I suggest that this interface should provide some means to do > > > that too. > > [RA] As I said, the application should not be figuring out wether to > rollback or not, the infrastructure should. > so it should be the reverse. there should be a way for the infrastructure > to notify the client about a rollback. > [SK] Agreed. But it will be good to shoot for some thing where there is no need to rollback. > I think the intention of abstracting the cluster manager to an interface is > > > to > > provide extensibility so that we can have different cluster manager > > implementations based on different group communication techniques. But I > > think right now the interface has introduced more coupling. > > > > Following is an approach which could reduce coupling and enable more > > flexibility and extensibility. > > > > Do we have the ability to register a listener to the Context? What I mean > > is > > an instance of a class which implements an interface ContextListner. The > > ContextListner has one method "notify" which take a parameter of > > type "Event". The ClusterManager interface can extend the ContextListner > > (BTW, Should ClusterManger be an abstract class?) > > [RA} unfortunately your replication points can be outside of the context > heirachy. [SK] I am sorry, I did not understand this. What else do you want to replicate. In a cluster what we need is state information to be replicated. There are two places where usually an application developer maintain state, the session and the database. I guess with the Axis2 context option he get a third place. HTTPSession and databases should not be our problem. Let that to be handled by the infrastructure providers of those two. But yes, we need to have a story as to how to get end to end state replication working. > For example instead of replicating every add/remove change happening > inside an invocation we can choose to replicate the net result (change in > state) at the end of the invocation. I think this is more efficient. The > decesion to replicate something should not be limited to be taken within > the context heirachy only. [SK] Yes this is efficient but leads to more conflicts. Why not let the end user (Application developer) decide that since he knows best the behavior of his application implementation. > There should be flexibility to call the ClusterManager from anywhere. So a > context listener is not sufficient. > [SK] Well this sounds bit dangerous :-). I am sorry, I don't have enough context here. > Furthermore your coupling is only reduced to the cluster manager. I also > didn't like the prospect of calling cluster manager from all over the > place, but given the current design of the context heirachy we have no > choice. > [SK] Well this actually could provide a good extension point to even application developers. In application server implementation of HTTPSession there is a way to register a listener. I have used it many times to clean up stale data in the session. But I may be wrong in this context. > The other more cleaner approach that I proposed a while back was to use > Aspects. We can use aspects to capture replication points using load time > weaving in a more non intrusive manner. This way the context code is not > littered with calls to the Cluster manager. I do have experimental version > on my local copy, but it still needs more work. > [SK] Aspect oriented approach work best when there are cross cutting concerns. I am not sure about the performance implications. I have used it for logging, tracing, throttling, etc. But certainly worth evaluating. > This way, in a particular node when there is change in the Context the > > > ClusterManager instance in that node get notify. Then that ClusterManger > > instance can mulitcast (reliable mulitcasting) the change to other > > ClusterManger instances running in other nodes. Since each ClusterManager > > instance has a handler to the Context it can apply the change locally. If > > the > > reliable multicast is configured to keep the "total order" in message > > ordering you don't have to worry about the conflicts due to concurrency. > > [RA] This is what happens currently. Context creations are notified > immediatly and state updates are notified at the end of an invocation. > Tribes which is a total odering reliable multicast then does the work. > However this will not prevent concurrency issues completely. Unless we do > pesimistic locking we would still experiance dirty reads and potential > write/write conflicts. > [SK] Well, total ordering to work, you need to maintain total ordering of events. In otherwords all the events occurred need to be notified. We can check with some carefull analysis whether causal ordering could work here. In that way things will be more efficient. Different group communication implementations are geared towards different QoS attributes. Application developer should have the flexibility to choose which one to go with. So we may want to enable different ClusterManger implementations to come in using different group communication implementations. However things can be futher simplify if we can make an assumption of a sticky session. I think that's some thing you can enforce and then manage simple complexities like transparent node recovery. With little feedback from the application developer this could also lead to flexible scalable implementation. I am just throwing out ideas so that we can trash out things. I suppose this is not information overloading :-). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
