On 13/11/2001 07:59 pm, "Mika Goeckel" <[EMAIL PROTECTED]> wrote:
> 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.
That's precisely what I'm thinking about...
> 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.
Indeed...
> 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.
If, in theory, the front module doing load balancing was able to see on the
spot who has the session (who's primary, who's backup) and adequately
redirect the request on the fly (it's possible to do it), then we achieve
sessions stickyness at the same time, and fail over in case things go
wrong...
> 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.
Can't help you on that... But, if we "customize" the lookup tables
abstracting it from JNDI, we could write also some C code for the web-server
modules that could participate in our session pooling group, and direct
requests where they should be, two pigeons with a single shot :)
Pier
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
