I introduced distinct commands (add/update/remove) to make it more simple and readable (to avoid update context being too complicated).
This also simplifies the clustering implementation, since an updateContext
message can be received before a contextAdded message due to the order in which the >threads run at a particular time. Afkam, I didn't encounter this during my very limited testing. However an update is always followed after a context is created. I am not sure how these events get mixed up due to thread issues. We should be able to garuntee causal ordering at the least. Can you explain the problem a bit more? To me the solution seems more of a hack due to some other issues in the system. Anyways if u think this change makes it easy, please go ahead with it. Regards, Rajith On 5/30/07, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Azeez, On 5/30/07, Afkham Azeez <[EMAIL PROTECTED]> wrote: > > I think there is no need for the contextAdded & contextRemoved methods > in the ContextManager interface. contextUpdated should suffice. > > The reason is, when a contextUpdated message is received, if it does not > exist on a particular node, it can be created. Similary, the context cleanup > mechanism will take care of cleaning up the contexts on each node, hence > removeContext is also not needed. This also simplifies the clustering > implementation, since an updateContext message can be received before a > contextAdded message due to the order in which the threads run at a > particular time. Otherwise, the sender has to ensure that always a > createContext message is sent to the channel before an updateContext message > is sent. > > Thoughts? Agree. +1 for the change. Chamikara -- > Thanks > Afkham Azeez > > http://www.wso2.org > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 -- Chamikara Jayalath WSO2 Inc. http://wso2.com/ http://wso2.org/ - For your Oxygen needs
