Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 36541]  -
    session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Message-Id: <20050909153751.F3AEC332@ajax.apache.org>
Date: Fri,  9 Sep 2005 17:37:51 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36541


------- Additional Comments From hwadechandler-apache@yahoo.com  2005-09-09 17:37 -------
(In reply to comment #71)
> Guys please .. Remy already said way back in #40 that he would look into 
> allowing this to be configurable :)

I don't really see anything that says the real issue will be addressed.  An out
of the box Tomcat has to be configured not to have a bug?  Plus, he said he
would look into it and all this and that and that's fine, but no where does it
reflect he believes there is an issue, and right now a bug caused by an
uninformed decision remains.  One, how do you synchronize calls with jsp:useBean
with scope of session?  Where else is session accessed in the Tomcat code
without synchronizing that developers should be aware of?  Is JSESSIONID stored
in the session as well and where is it accessed?  We need to make sure that
access is synchronized.  If we are going to talk about specifications and
responsibilities lets talk about them, but logically and truthfully.  There is
more to this issue than can be addressed by: "It's the developers
responsibility.".  Do we need to file bugs for all of the other issues if this
is going to remain invalid?  I say that must be the case if this is to remain
invalid.

Personally I don't like the idea that "this was done as an experiment"...
written in one of the comments above... in a system said to be "production
quality" (Tomcat home page).  The point is this: if it were an experiment it
should have used an option to turn it on, but should not have been a default by
any means.  If a system has an apparent flaw that reduces it's stability and
reliability and  especially when it can be solved with a couple of lines of
code.....a patch is a no brainer.  This entire issue makes Tomcat currently
invalid as there are sections of standard usage which can not be safe guarded
against concurrency issues.  If I have an issue where customers can get kicked
out of the site after being logged in and the client asks me to fix it....I
can't without changing the entire application, and by that I mean not using
jsp:useBean calls in my JSP pages without wrapping them with other calls, so
what's the point of using the tags in JSP if they can't be safe guarded without
more work.  I thought the point of the tags, EL, and other things is to make
development quicker and to provide short cuts.

My opinion:

1) Before a decision was made to change the synchronization of something which
was currently synchronized when documentation for the underlying implementation
explains there are issues with not synchronizing should not have only been
discussed as to whether it was safe, logical, and correct, but should have been
proved.

2) If it were to be an experiment, then it should have used an option to turn it
on, and the default been the more correct implementation for the given situation.

3) When a problem is identified in a piece of software being promoted as
production ready it should be handled.  Not shaken off as INVALID.  Where is the
proof that unsychronized reads don't have issues.  Examine the HashMap source
code and write a few tests.  You'll see with the bouncing index that a valid
value can exist in the Map for a given key and that Entry not be located because
null is returned.  Thus a program relying on a session variable to be set will
not be able to retrieve that session variable and take an entirely different
path because of this....it's very simple........just read the code:
    public Object get(Object key) {
        Object k = maskNull(key);
        int hash = hash(k);
        int i = indexFor(hash, table.length);
        Entry e = table[i]; 
        while (true) {
            if (e == null)
                return e;
            if (e.hash == hash && eq(k, e.key)) 
                return e.value;
            e = e.next;
        }
    }

between the time i is set from a call to indexFor if table is resized with all
values null or all items are transfered and the given index for i is null then
null is returned as soon as we step into the while loop.  What that means is: If
between the time i is set from indexFor and the HashMap is resized because of a
write then there is a concurrency issue which affects the consistency of the
application.

How can this issue be worked around currently using Tags?  If we need to file
bugs on all the other places please let us know.  If you would like some help
with the other issues I would be willing to help, but my feelings are this
should be changed back for the time being and we need a new release based on the
latest release with only this change to the source.  In the mean time all the
other issues can be worked on as all of that will take more time than this
change.  Once those issues are dealt with then change it back and make sure the
issue is documented on the front page of the Tomcat documentation.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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