I've been lurking and searching through the archives searching for an
answer to the issue which was eventually reported as bug #739 I've
found some excellent descriptions of the problem but have been unable to
discover a solution in the archives. I was hoping that someone can
point me towards a
Gokul Singh wrote:
Hans Bergsten wrote:
> [...]
> The spec may not be explicit enough about this, but the session object
> you get back from the getSession() object is a container-managed
object
> that the application is not supposed/allowed to keep long-lived
> references
> to. It's the same a
Gokul Singh wrote:
>
> - Original Message -
> From: "Hans Bergsten" <[EMAIL PROTECTED]>
>
> > > Gokul Singh wrote:
> > >
> > > Hans Bergsten wrote:
> > > > [...]
> > >
> > > I am trying to disallow a single user to have multiple login sessions
> > > valid at any given time. I have to en
- Original Message -
From: "Hans Bergsten" <[EMAIL PROTECTED]>
> > Gokul Singh wrote:
> >
> > Hans Bergsten wrote:
> > > [...]
> >
> > I am trying to disallow a single user to have multiple login sessions
> > valid at any given time. I have to enforce this even if the user tried
> > to
> Gokul Singh wrote:
>
> Hans Bergsten wrote:
> > [...]
>
> > The spec may not be explicit enough about this, but the session
> object
> > you get back from the getSession() object is a container-managed
> object
> > that the application is not supposed/allowed to keep long-lived
> > references
Christopher K. St. John wrote:> > All I'm saying is that
it's dangerous to rely on behavior> > that's not clearly defined by
the spec, > >> But give me a break: what JServ
is doing in this case> is just fantastically counterintiutive.
I agree with Chris on this.
> This probably needs t
Hans Bergsten wrote:> [...]> The spec may not be explicit
enough about this, but the session object> you get back from the
getSession() object is a container-managed object> that the application
is not supposed/allowed to keep long-lived> references > to. It's
the same as with all other cont
"Christopher K. St. John" wrote:
> "Craig R. McClanahan" wrote:
> >
> > If your server implements session swapping or distribution (as we are currently
> > developing in the 4.1 repository), it is pretty much guaranteed that different
> > session object instances may be used during the lifetime o
"Craig R. McClanahan" wrote:
>
> If your server implements session swapping or distribution (as we are currently
> developing in the 4.1 repository), it is pretty much guaranteed that different
> session object instances may be used during the lifetime of the same session.
>
But don't you get
Hans Bergsten wrote:
>
> 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
> a
Hans Bergsten wrote:
>
> 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.
>
You can see more tha
"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
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
"Christopher K. St. John" wrote:
>
> Hans Bergsten wrote:
> >
> > The spec may not be explicit enough about this, but the session object
> > you get back from the getSession() object is a container-managed object
> > that the application is not supposed/allowed to keep long-lived
> > references
>
Hans Bergsten wrote:
>
> The spec may not be explicit enough about this, but the session object
> you get back from the getSession() object is a container-managed object
> that the application is not supposed/allowed to keep long-lived
> references
> to. It's the same as with all other container-o
> Another solution, IMHO, is to make sure all these objects are only used
> within the thread they where allocated for. Briefly, add a package scope
> setThreadID() method to the classes that implement pooled objects like
> this and let the container call this method with the current thread ID
>
[EMAIL PROTECTED] wrote:
>
> > There lies the catch and the source of problem in my understanding.
> > In different requests relating to
> > the same session, I may get referance to HttpSessionFacade instances which
> > are different, but I expect them to be same (although not guarantied by
> >
Gokul Singh wrote:
> [...]
> > The reason you see a behavior difference is that Tomcat 3.1 did not
> recycle session object instances, but Tomcat 3.2 does.
>
> There lies the catch and the source of problem in my understanding.
> In different requests relating to
> the same session, I may get re
> There lies the catch and the source of problem in my understanding.
> In different requests relating to
> the same session, I may get referance to HttpSessionFacade instances which
> are different, but I expect them to be same (although not guarantied by
> specs but I thought it was a tacit agr
- Original Message -
From: Craig R. McClanahan
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Thanks for looking into the problem. I think the I was not able to convey
the problem properly. I have some clarifications below.
> The session object is valid for more than one request, but only u
20 matches
Mail list logo
