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:43:57 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 hwadechandler-apache@yahoo.com  2005-09-08 16:43 -------
(In reply to comment #38)
> (In reply to comment #37)
> > If the read operations happens to bump into this moment of temporary
> > inconsistacy the infinite loop can occur.
> 
> All the entry objects will be mutated. While it may be inconsistent and might
> loop for an instant (although I am not convinced this could really be the case;
> I think the trouble without any sync could only occur if there was more than one
> concurrent unsynced write, and in particular, two "remove"), the pointer value
> will be corrected and the loop should exit. That's my interpretation looking at
> the code. I think I'll write a small program to test this.
> 
You can certinaly get null returned when a valid value was added to the Map
previosly as well because of the inconsistency.  The hash index used to locate
the first Entry is based on the hash and the length of the table (I guess we
should say the chosen bucket).  If the value has been added to the map.  Then a
call for a get occurs and a call for a write and the write makes a resize and
the resize changes the location of the bucket then e could match another Entry
besides the one for the correct hash then you start getting into some looping. 
In a test I had a get interation of 4 times occur when this happened, but
considering all of the possible shifting that can occur I'm not convinced that
an infinite loop could not occur.  Given the bucket index algorithm and all of
the possible values for a hash and a table size I don't think one can safely say
it's not possible without synchronizing.  If there is a way to determine that
the behavior of one search for a bucket with any hash is always going to produce
the same result for any size table then I think you can safely not synchronize
the code.(In reply to comment #38)
> (In reply to comment #37)
> > If the read operations happens to bump into this moment of temporary
> > inconsistacy the infinite loop can occur.
> 
> All the entry objects will be mutated. While it may be inconsistent and might
> loop for an instant (although I am not convinced this could really be the case;
> I think the trouble without any sync could only occur if there was more than one
> concurrent unsynced write, and in particular, two "remove"), the pointer value
> will be corrected and the loop should exit. That's my interpretation looking at
> the code. I think I'll write a small program to test this.
> 

You can certinaly get null returned when a valid value was added to the Map
previosly as well because of the inconsistency.  The hash index used to locate
the first Entry is based on the hash and the length of the table (I guess we
should say the chosen bucket).  If the value has been added to the map.  Then a
call for a get occurs and a call for a write and the write makes a resize and
the resize changes the location of the bucket then e could match another Entry
besides the one for the correct hash then you start getting into some looping. 
In a test I had a get interation of 4 times occur when this happened, but
considering all of the possible shifting that can occur I'm not convinced that
an infinite loop could not occur.  Given the bucket index algorithm and all of
the possible values for a hash and a table size I don't think one can safely say
it's not possible without synchronizing.  If there is a way to determine that
the behavior of one search for a bucket with any hash is always going to produce
the same result for any size table then I think you can safely not synchronize
the code.

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