Return-Path: Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 58819 invoked from network); 28 Sep 2000 14:28:13 -0000 Received: from anchor-post-32.mail.demon.net (194.217.242.90) by locus.apache.org with SMTP; 28 Sep 2000 14:28:13 -0000 Received: from alfie.demon.co.uk ([158.152.44.128] helo=bagpuss.pyrites.org.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13eefO-00077E-0W for tomcat-user@jakarta.apache.org; Thu, 28 Sep 2000 15:28:06 +0100 Received: by bagpuss.pyrites.org.uk (Postfix, from userid 1000) id 8A90F7D29; Thu, 28 Sep 2000 11:03:06 +0100 (BST) To: tomcat-user@jakarta.apache.org Path: not-for-mail From: Nick.Holloway@alfie.demon.co.uk (Nick Holloway) Newsgroups: list.tomcat-user Subject: Re: Problems with invalidate Date: 28 Sep 2000 11:03:06 +0100 Organization: Alfie's Internet Node Lines: 50 Sender: Nick.Holloway@pyrites.org.uk Message-ID: <8qv50q$pjg$1@alfie.demon.co.uk> References: X-Newsreader: NN version 6.5.0 CURRENT #119 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Mirek.Subrt@intax.cz writes: > Can you tell me, why session.invalidate() and session.putValue() methods > work only with Tomcat 3.1 and not with Tomcat 3.2 beta 3? > [...] > session.invalidate(); > session = request.getSession (true); > beanX=new Vector(); > session.putValue("beanX", beanX); The behaviour you were relying on in 3.1 was that if the current HttpSession was not valid, then a calling "request.getSession(true)" would create a new session. The documentation I have to hand (servlet23_PublicDraft1) has: public HttpSession getSession(boolean create) Returns the current HttpSession associated with this request or, if if there is no current session and create is true, returns a new session. If create is false and the request has no valid HttpSession, this method returns null. It would seem in Tomcat 3.2 once the session is associated with a request, it remains associated, even though it is no longer valid. This doesn't actually conflict with the first paragraph. However, there might be a bug in 3.2 (looking at the old copy of the code I have) in that the following code would not return null, but will return an invalid session, which conflicts with the second paragraph. session.invalidate() session = request.getSession(false); Try reporting the behaviour you are seeing as a bug, and see if it a) either gets fixed, or b) it is confirmed as being part of the specification. You could avoid this problem entirely by re-using the session object, but manually clearing all elements. Enumeration names = session.getAttributeNames(); while ( names.hasMoreElements() ) { session.removeValue( (String) names.nextElement() ); } -- `O O' | Nick.Holloway@pyrites.org.uk // ^ \\ | http://www.pyrites.org.uk/