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: <20050909102644.35EF232B@ajax.apache.org>
Date: Fri,  9 Sep 2005 12:26:44 +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 struts_user@anotheria.net  2005-09-09 12:26 -------
Another question:

http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

According to sun's javadoc principals (above link)
#  The Java Platform API Specification is a contract between callers and
implementations.

The Specification describes all aspects of the behavior of each method on which
a caller can rely. It does not describe implementation details, such as whether
the method is native or synchronized. The specification should describe
(textually) the thread-safety guarantees provided by a given object. In the
absence of explicit indication to the contrary, all objects are assumed to be
"thread-safe" (i.e., it is permissible for multiple threads to access them
concurrently). It is recognized that current specifications don't always live up
to this ideal.

Since the javadoc of the HTTPSession
(http://java.sun.com/j2ee/1.4/docs/api/index.html) doesn't mention anything
about session being not thread-safe, should not the developer be able to rely on
the fact that the implementation is thread safe?


-- 
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