One question - wouldn't be better if the 'distributed session management' would be first designed and discussed _outside_ of the ServletSession context ?
In other words, a SessionManager that would store and provide fail-over, etc for serializable objects. It can have a rich interface, including support for transaction, control sync/async storage, etc. There are many limits in what you can do with a servlet session - all you have is a get/set with Objects ( serializable or not ). No way to guess if the user cares about the object or is just a cache ( in which case it can be a blob that the user just doesn't want to read again from net/disk ). No way to tell the user that his object was stored sucessfully or lost ( you need transactions and exceptions for that ). Designing the SessionManager as a standalone component would make a lot of sense - you can then integrate it with the servlet sessions, or the user could use its richer API. IMHO no sane user should store something in a servlet session and assume the operation will be sucessful - and the session manager can only give a dangerous ilusion that this is possible. Nothing can be guaranteed to allways succeed ( no database or network application can do that ) - and with an API that doesn't provide any feedback there's little you can do. Writing a servlet application assuming the session data will be safe is at least not portable ( assuming it is possible, which I doubt ). At least with a standalone SessionManager you can include the lib in your war and have it working on any container. ( by standalone I mean a user-space util, independent of the servlet container, but with hooks - so it could be hooked into a container as a default session manager or used as an addon ) Costin > > 1) 10 Tomcat webservers (1-10). Servers 1 and 2 happen to be > > identifed as 'Session Managers' as well as web servers. > > Servers 3-10 are just plain web servers, not session managers. > > > > In this scenario, Tomcat servers 1 and 2 are burdened by satisfying > > session requests (queries & updates) from the other 9 servers, as well > > as handling their own web-traffic. They must also initiate > communication > > to the other 9 servers whenever a session is invalidated (due to > update, > > maxAge, or on demand). They must also communicate all session deltas > > to the 'other' session manager. > > The best scenario, but tell me if I misunderstand something after you've > reviewed case 4. > > > > > 2) 10 Tomcat webservers, all 10 are identified as 'Session Managers' > > > > In this scenario each Tomcat must communicate session deltas to each > > of the other 9 servers. All servers must perform significant extra > work > > in order to keep their Session store up-to-date. > > > > 3) 10 Tomcat webservers, 2 separate Session Managers. > > Tomcats 1-5 point to SM1, Tomcats 6-10 point to SM 2. > > > > In this scenario, each Tomcat only communicates with 1 > > session manager. Each session manager communicates > > session deltas with the other SM, and with only the Tomcat > > servers that it connect themselves to it (5 in this example) > > on an as-needed basis (e.g. when the Tomcat instance asks > > for the session data). Each SM must also send tell all it's clients > > when sessions are invalidated. > > > > Fail-over could be handled in a similar manner in all scenarios. > > Addition of a new SessionManager (or SessionManager capable Tomcat) > > could be handled in a similar manner in all scenarios. > > In principle, I completely agree. All I want to express is, that I think we > don't need SessionManagers as assigned responsibility and would save > traffic. > > Scenario: > > 4) 10 Tomcat webservers acting as SessionManagers for Sessions initially > created by themselves or being assigned responsibility afterwards for a > specific session. > In this scenario every Tomcat backs up sessions to a configured number of > others (for simple redundancy only with one other tc) The session is > primarily held on the TC which created it or most recently used it. The > other instance(s) hold a passive copy for fail-savety. > a) A dumb load.balancing facility passes a request to a completely different > TC which needs control over the connected session. From a regularly updated > list or by asking it's peers it get's the (actual) owner of that session and > requests to take over ownership. The old owner drop's ownership after the > session has been taken over. Alternatively the old owner becomes the backup > and the old backup drops. > b) A clever load-balancing facility remembers where the last request of this > session went and directs the next request to the same TC. The TC has all > what it needs to fulfill the request and communicates the changes of the > session afterwards. > In Scenario a) you have one session copy before the request and one change > communication afterwards. > in b) only change communication. > > In your scenario, the TC needs at least the certitude that the session is > uptodate, so it goes asking the SessionManager. If yes, it's case 4 b) > If no, it's case 4a) but in both cases the overhead of asking the > SessionManager. > > If the primary owner goes down, the secondary becomes primary owner and has > to find a new secondary. If that happens, 4a) applies because the > load-balancer needs to choose another instance and the likelyhood that it > finds the backup TC by chance is 1/(number of nodes - 1). > > Assumption: We leave the load-balancing to the load balancer. > > Without that assumption we could be even more clever: > > A TC gets a request and hasn't got the session. But from the list or by > asking it's peers it get's knowledge who is the primary owner. It asks > mod_webapp to go and send the request to that TC. In that case we end up at > 4b) in nearly every case. No session copying during the request, only > changes afterwards. > > After having written that I notice that we are very close in our thinking. > Your approach is somewhat clearer by the sake of having one more copy of a > session, instead if the SessionManager part of a TC stores it's copies in > the TCs session store (memory presumably). Then we have exactly the same. > > I'm playing around with the TC src at the moment. I've had a look on > JNDIRealm to find out how a Context is usually created. I'm missing a static > service utility with a simple getInitialContext method and more than that > Log4J.... and are there really JUnit tests around? I've not seen a single > one. > > Cheers, Mika > ^X^C > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
