tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Thu, 08 Sep 2005 14:27:48 GMT
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 remm@apache.org  2005-09-08 16:27 -------
(In reply to comment #39)
> Let me ask you another question then.  Where is the written specification for
> the HashMap that states your usage is safe ?  It sounds like you as working on
> the presumption that all implementation's won't cause an infinite loop (or set
> fire to the computer) but you dont have any API contract to back that
> presumption up.
> 
> I read the specification to state that some put/remove operations (that modify
> the map structurally are explicitly not threadsafe)
> 
> You can't call threadsafe and non-threadsafe calls to an API at the same time. 
> The threadsafe calls are only threadsafe with respect to other threadsafe calls
> on the same API.
> 
> My understanding of this:
> 
> You can call threadsafe API calls at the same time.
> 
> Anytime you want to call a non-threadsafe one you have to serialize it with
> respect to the API Interface not with respect to itself or other similar
> operations (unless otherwise stated).

I guess if it goes back again to lawyerspeak level rather than logic, then
there's nothing to talk about. It is all related to reasonable reliability and
robustness, and I don't believe the algorithm of a hashmap can become that weird
(the Sun structure is already not particularly safe). I mean, there could even
be bugs in the collection implementation too. 

I'd like to remind you once more that this synchronization in the container is
not mandatory from what I can see, and at least one other popular container
apparently behaves like Tomcat 5.0. It's the end of this discussion thread as
far as I am concerned :)

I'll also add a way to configure size and sync of the collection (assuming I
confirm behavior to be acceptable using a test program).

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


Mime
View raw message