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 13:14:04 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 darryl@darrylmiles.org  2005-09-08 15:14 -------
(In reply to comment #34)
> No, because at this point I believe making sure that the HashMap does not get
> corrupted (using syncs on put and remove) is enough to guarantee that the get
> method doesn't enter an infinite loop (by returning null, or the result when
> there's a problem - it will be unpredictable, but seems to me equivalent to the
> higher level concurrency issues if you mix and match reads/writes in the webapp
> for critical data without being careful).

I understand the point that others are making for all access needing the same
sychronization.

I don't understand your logic that read/get don't need syncronization.

The issue with the infinite loop read stems from the fact that two different
threads access the map at the same time.  One for read and one for write, while
the writer is modifying the map it corrupted the pointers the reader is using to
traverse the data structures and thus enters an infinite loop (due to the
HashMap design, other collection classes can detect some situations and throw an
exception for ConcurrentAccessException).

This is because there is no synchrnozation between get/put operations.  Only
between puts.



As I pointed out in the TC user mailing list, it would be possible to use a
ReadWriteLock to allow threading of multiple readers to take place.  But while
there is one writer working on the Map you need to be sure no reader is using
the map too.

Introducing the ReadWriteLock might introduce an unwanted JDK5 dependancy, I
think its a new JDK5 concurrency class ?  It might also be slower than a regular
synchronized lock.  But without benchmarks we wont know.


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