----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Cc: "Tom Drake" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 1:05 PM Subject: Re: Tomcat: Distributed Session Management revisited
| | One question - wouldn't be better if the 'distributed session management' | would be first designed and discussed _outside_ of the ServletSession | context ? I agree. | | 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. True, but I'm not sure that exposing a Session Manager api to the application programmer is a good idea. It's not part of the Servlet API, for one thing. For another, many people have a difficult enough time just understanding the existing api. (witness recent discussions on the tomcat-user list re: "non-serializable objects in sessions"). | 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. In any servlet container, one must be able to count on this functionality. In a distributed environment, it is encumbant on the application programmer to ensure that any objects placed in the servlet container are serializable (It says this in the servlet spec - I don't remember the section number - possibly 7.7.3) In fact, JSP's depend on this behavior. | | 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 ) | Indeed, this would be an advantage of such a session manager. | | 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]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
