Guys, I have recently been thinking a bit about my next iteration on distributable HttpSessions for JBoss/Jetty.
I have turned up a number of thorny issues which I have not seen discussed anywhere. My reading of the spec is that it avoids all of these issues by only ever allowing one copy of a session to be active at one time i.e. it talks about migrating sessions from one server to another - but not (as I recall) replicating them. I see the following problems with replication : 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. If not, then we assume that all resources being managed by these listeners are distributed and not local, since notifications involving different parts of their lifecycle may arrive on different nodes in the cluster. 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 ? Let's say we start a new nodeB and deploy a webapp on it. This webapp is already running on another nodeA. A request for this webapp somehow arrives at nodeB. Does nodeB notify activation listeners ? If so, then for the sake of symmetry, nodeA should have notified passivation listeners. Pursuing this to it's logical conclusion, every 'snapshot' and distribution of a session might need to notify first passivation and then activation listeners. Activation/Passivation is too expensive to do this frequently. I am interested in how others have resolved these problems, or have they been largely ignored in other implementations ? 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'. Notification of change is only made on the 'active' session. The token designating 'activity' is passed around the cluster in the form of client requests. If we can avoid two requests accessing twin sessions on different nodes at the same time we can adhere to the spec's model of how this should work. Session affinity will go most of the way to fulfilling this requirement, but there will be cases when it will fail. In these cases, behaviour will be unpredictable - can we prevent this ? OK - I'm rambling, and it's past my bedtime. Does this make any sense to anyone ? Has anyone anything to add ? This session stuff is not as simple as I first thought ! Jules P.S. going with the only-one-active-replicant approach assumes that all resources managed via session listeners are distributed also. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
