"Christopher K. St. John" wrote:
>
> Hans Bergsten wrote:
> >
> > "Christopher K. St. John" wrote:
> > >
> > > 7.3 Session Scope
> > >
> > > HttpSession objects must be scoped at the
> > > application / servlet context level. The
> > > underlying mechanism, such as the cookie
> > > used to establish the session, can be shared
> > > between contexts, but the object exposed, and
> > > more importantly the attributes in that object,
> > > must not be shared between contexts.
> > >
> > > By mentioning that the HttpSession object cannot
> > > be shared outside the ServletContext, it strongly
> > > implies that it can be shared within the context.
> > > If that sort of thing isn't allowed, then 7.3 might
> > > need to be clarified.
> >
> > This section refers to the fact that a servlet in one context should
> > not be able to gain access to the same session data as a servlet
> > in another context (i.e., resources in two different context's can
> > not "be part" of the same session) for security reasons .
> >
> > It has nothing to do with whether a servlet in one context is allowed
> > to hold on to the actual session object or not, which has to do with
> > how much freedom the spec gives to container vendors in terms of
> > pooling and life-cycle management for the internal objects.
> >
>
> Because Section 7.3 explicity discusses the HttpSession
> object itself (as opposed to the objects it contains), it
> suggests that the HttpSession object has an identity.
>
> I don't think there is any question that after the end
> of the lifecycle of an HttpSession object, it can be
> recycled. But what earlier messages in this thread suggested
> was that JServ was recycling HttpSession objects _during_
> the lifetime of the session, so that req.getSession(false) could
> return two different objects even within the same session.
>
> That would mean that the practice of synchronzing on the
> HttpSession object was also not kosher? Since two servlets
> within the same session at the same time could not be sure
> of getting the same HttpSession object? Are you really
> suggesting that that behavior is allowed by the spec?
All I'm saying is that it's dangerous to rely on behavior that's
not clearly defined by the spec, and that I'm pretty sure that
whatever it is you want to do can be done in a way that's more
likely to be portable than relying on any particular behavior
in Tomcat with regards to the container-managed objects, like
HttpSession, HttpServletRequest etc.
I agree that it's reasonable to assume that the same HttpSession
instance is used throughout the session in the most common case,
but I don't agree that the spec mandates this implementation (and
I don't think it should mandate implementation details unless it's
absolutely necessary for portability). But in a container that
saves sessions to disk to conserve memory, or during server restart,
you will most definitely see more than one instance. Same thing
for a distributable application, where the session may migrate
to another server.
Why would you synchronize on the HttpSession instance? It's
up to the container to make sure that you can add and remove
objects from the session in a thread-safe manner. If you need
to synchronize for thread-safety of your application objects,
sync on the application object or an internal "lock object"
instead.
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
