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:56: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 16:56 -------
(In reply to comment #40)
> > 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.


There is nothing weird about anything.  Its basic computer programming design.

If you write a program what uses another API and you make presumtions about how
you can use it then you will come unstuck, not matter what any servlet
specification says.

If however you base it on whats is written into the contract of what the API
presents to your application then you can legitimatly point the finger at that
API when you find a problem.

Maybe you should write your own Map interface to get the bahaviour you want, I
think a generic ReadWriteLock protected Map interface would be a good thing for
the wider Java community to have access to.

Your approach for writing a test case to prove the problem is valid, because its
a concurrency rare case, maybe if you sprinckled Thread.sleep() throughout the
HashMap code to slow it down the you might be able to make the problem 100%
reproducable.

But I don't believe Sun's implementation needs to be fixed, as this problem does
not seem to contradict the written contract the HashMap API presents.


> I'd like to remind you once more that this synchronization in the container is
> not mandatory from what I can see

And I'm not disputing you.  I'm disputing the more fundimental usage problem. 
There is no way for a wep-app to override the Session object in a portable way
across containers.


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

This would be welcomed by me.


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