>1. create/modify/destroy session events >---------------------------------------- > >If a session is created/modified/removed on NodeA, should listeners >attached to a replicant (or the replicant's context) be notified on NodeB ? > >If so, we open another nasty can of worms, since we need to guarantee >the order in which modifications arrive at NodeB from other Nodes in the >cluster. Furthermore, code that manages distributed resources via these >notifications, and work in the webapp in non-distributed mode, may >break. e.g. code that allocates/deallocates a distributed resource on >session creation/destruction will have to reference count >creation/destruction so that the resource is allocated/deallocated at >the correct times. Even then, if a node goes down, serious problems >arise - the system begins to look very fragile.
JavaGroups has a ORDER protocol that guarantees the order of messages being sent. Also, the prototype implementation that i did, (see my article http://www.theserverside.com/resources/article.jsp?l=Tomcat) works fine in all these scenarios. >2. activation/passivation/distribution >--------------------------------------- > >The spec requires notification of the relevant listeners on the >activation/passivation of a session. Ignoring the problem in (1) another >issue still remains. Does the distribution of a session constitute a >passivation/activation cycle ? >I am interested in how others have resolved these problems, or have they >been largely ignored in other implementations ? I believe we should have a config flag, whether to notify listeners of attribute changes when a replicated session receives a state. But I believe that other vendors have ignored this. The only thing they guarantee is that the session contents are replicated, nothing else. Then they leave it up to the programmer to handle the rest. >In writing this I am beginning to think in the following way : > >The spec resolves all of this by only allowing one 'active' copy of the >session at any one time. I think that one way around these problems may >be to assume that only one replicant at any one time is 'active'. Again, in my prototype implementation every session is 'active' hence you can use non-sticky load balancing. but this is not the optimal solution. But I would recommend that a listener should be notified if setAttribute is called from the servlet, which indicates that you session is active. when the replicated session receives a 'setAttribute' message, it should call something like setAttribute(attr, doNotNotifyListenerFlag); > >Does this make any sense to anyone ? yes it does! > >Has anyone anything to add ? I will, I'm currently finishing up another project, then I will have some more time for this stuff. > >This session stuff is not as simple as I first thought ! it is not that hard either, the key is to keep it simple :)) but defining the requirements first, ie, if listeners should be notified or not, I would say that we shouldn't be notifying listeners on the replicated sessions, we should only replicate state, not logic. that way we can have an initial implementation working pretty quickly, and then we can do more advanced stuff. /Filip _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
