----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> Nic Ferrier wrote:
>
> > >>> Gokul Singh <[EMAIL PROTECTED]> 11-Jan-01 10:57:59 AM >>>
> >
> The problem is that Gokul is expecting the contents of the session
instance he
> stashed to be relevant after the session has been invalidated.
This is not what I am expecting. The session is valid. It was not
invalidated it & it did not timeout.
> At *best* he
> should expect to get IllegalStateException errors when he references it
after
> invalidation -- at worst he gets undefined behavior because he is outside
the
> boundary of what the spec guarantees.
Agreed. But this is not what I am doing. You can remove the lines of code
listed below from the code I posted and still you will get the Exception.
Remove the following two lines and follow the steps mentioned in the earlier
mail to reproduce the error.
==================
if(objSession != null)
objSession.invalidate();
==================
>
> In particular, the behavior difference between Tomcat 3.1 and 3.2 is that
3.1
> did not recycle session object instances, and 3.2 does.
There lies the catch and the source of problem in my understanding. The
instances are recycled, but should'nt the HttpSessionFacade be tightly
linked to the HttpSession it wraps around? 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 agreement between container and servlet
developer). What I suggest is that tomcat should recycle the
HttpSessionFacade instance only when the HttpSession instance is
recycled.This might be more inefficient as it will result in N instances on
HttpSessionFacade if there are N valid sessions on the server, where as in
the present scenario, if my understanding is correct, there will be X
instances of HttpSessionFacade if there are X simultaneous requests. and X
is less than N.
To be more elaborate:
Lets us assume the following scenario.
1. A request comes which creates a new session. A HttpSession object (HS1)
is created and the Facade object (HSF1) wraps around it.
2. I store a referance to the session in the context that is a handle to
HSF1 which maps to the userid.
2. Another request comes from the same session . The object made available
to the request is not necessarily HSF1 and may be HSFx which wraps around
HS1.
3. At this point in time HSF1 may wrapped around another instance of HS or
nothing at all ( null).
4. I get the handle to the session which I want to invalidate from the
context which is HSF1. Now I am in trouble due to the point above.
In my opinion HSF1 should not refer to any other session till HS1 is
invalidated (or timed out).
What should I do to avoid this problem?
Why am I doing this? I want to prevent double login of the same user and on
the second login want to invalidate his previous login. The second login may
be from a different machine with no valid session.
> > PS with 2.3 API we will have other ways of managing sessions (the
> > session lifecycle events) but you still couldn't do this particular
> > trick without storing the session reference somewhere.
> >
>
> Yes, and with session event listeners, you are notified when the session
is
> invalidated, so you can immediately remove your reference to it.
I do that. But it is not about invalid sessions. The problem is about valid
sessions.
>
> Craig
>
Regds,
Gokul
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
