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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
