Dear servlet container developers, this is a proposal in order to improve the session management with respect to saving of third party server side resources. This is the same proposal I've sent as feedback to the "Java Servlet Specification Version 2.4 Proposed Final Draft August 5th 2002" (see below). Although not (yet?) part of the Servlet Specification as a must, it doesn't contradict the current or the upcoming specification. Therefore, I suggest that you implement the described feature with Tomcat just soon if you would agree to the proposal.
I'm not a subscriber of the tomcat-dev mailing list. So I'd be pleased to receive any reply with the sender's address of this message. Kind Regards Helmut Barthel [EMAIL PROTECTED] -----Ursprüngliche Nachricht----- Von: Helmut Barthel [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 4. Oktober 2002 15:56 An: '[EMAIL PROTECTED]' Betreff: A new session should be invalidated automatically with response failure Technical Feedback to "Java Servlet Specification Version 2.4 Proposed Final Draft August 5th 2002" SRV.7.5 Session Timeouts ------------------------ Comment: A paragraph like the following should be appended: 'The container must invalidate a new session immediately if itself has finally found out that the session creating request cannot be responded successfully.' If the container itself knows that the client will never be able to join the prospective session it should be required to invalidate such a useless session object in order to release resources already bound to the session, as soon as possible. Discussion: A logon servlet will often allocate special server side resource objects and bind them to a newly created session object. If the container cannot finish the response to the logon request for any reasons the then useless session object continues to exist. Hence, the resources remain bounded to it until the session times out. This situation can arise easily, for example, because of impatient users. If the resource allocation takes some time, that user species will probably click the logon button again (or the cancel button of the browser and then the logon button again). Hence, the user caused valuable resources to be allocated twice. Let's tighten up this scenario: The resource provider may request for the user's name and may be configured in order to allow only one allocation per user at a time. Then the impatient user will lose the firstly allocated resource (now parked with the unjoinable first session) and will get an "already connected" message from the resource provider while answering the second logon request. Though the user is guilty, he will probably become angry, nevertheless. As a thinkable workaround, the servlet programmer could bind an allocated resource to the session as late as possible in the logon servlet's service method - after testing the connection to the client: HttpSession session = request.getSession(); SomeResourse resource = null; if (session.isNew()) { resource = ... // allocate the resource try { response.setBufferSize(<large enough value>); ... // write the response's success output response.flushBuffer(); // test the client connection! session.setAttribute("SomeResource", resource); // bind now } catch (IOException e) { // javax.servlet.ServletException: // Connection reset by peer: socket write error resource = null; // release the resource session.invalidate(); } return; } Such a workaround is neither generalizable to all possible programming requirements of the servlet, nor it is guaranteed to work well with all container implementations (e.g., the flushBuffer method is not *required* to throw the declared IOException). Kind Regards Helmut Barthel [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
