tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Helmut Barthel" <helmu...@sapiens.com>
Subject WG: A new session should be invalidated automatically with response failure
Date Tue, 08 Oct 2002 08:17:14 GMT
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
helmut.b@sapiens.com


-----Urspr√ľngliche Nachricht-----
Von: Helmut Barthel [mailto:helmut.b@sapiens.com]
Gesendet: Freitag, 4. Oktober 2002 15:56
An: 'servletapi-feedback@eng.sun.com'
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
helmut.b@sapiens.com


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message