Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Date: Mon, 7 May 2001 11:18:41 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PROPOSAL Tomcat 4.x] Cluster
In-Reply-To: <3AF6DC8B.3A538E6F@razorfish.com>
Message-ID: <Pine.BSF.4.21.0105071114020.9125-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 7 May 2001, Bip Thelin wrote:

> [SNIP]
> 
> Do we really need to lock a session for each request and then
> replicate it? Sorry I might be confused, you mean a request for a
> session or a request as in generating a new request object(http
> request). If we assume that a session is only in use in one JVM at a
> time(which I think we can assume) then that session doesn't need to be
> locked it just needs replication when it's changed.
> 

The servlet spec *requires* that all requests for a given session, at any
point in time, be served by a single JVM.

Whether and when replication happens seems to me like a quality of service
issue for different implementations of the cluster -- I don't think a
single answer will suffice here.  I can conceive of everything from never
migrating an existing session (essentially what the current "load
balancing" support provides) to duplicating every single change live.

An interesting question is, how do you detect when a session has been
"changed"?  Obviously, you can detect setAttribute/removeAttribute, but
what about changes to the *internal* state of the attributes themselves
that the session does not know about?  (I understand, but haven't
verified, that some J2EE containers expect you to call setAttribute again,
on the same attribute, to tell the container that you've modified
something).

Craig