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 14:08 ------- (In reply to comment #31) > No this means that the statement of the HashMap authors: > * <p><b>Note that this implementation is not synchronized.</b> If multiple > * threads access this map concurrently, and at least one of the threads > * modifies the map structurally, it <i>must</i> be synchronized externally. > also applies to x Reader, one Writer, so synchronizing "writes only" is a > misusage of the HashMap according to the documentation. It's cool, but I have not asked for the nth lecture of this portion of the javadoc. How about trying to answer my question ? It doesn't seem that hard. > On the other hand, I made some measures and calculated how much performance > you > gain by removing synchronization from get/set methods. > I compared the performance of synchronized hashmap access against not > synchronized (singlethreaded, pIV 2.8 Ghz, HT) and calculated that you gain > 230 > milliseconds on 3,000,000 operations! > That is 0.00008 milliseconds per operation. Even you would have 100 accesses > to > the session from 100 parallel threads, it would cost you additional 8 milliseconds. > According to alexa.com we have an average response time of 0.8 seconds (for > the > user) and are faster then 80% of the net (google's average is 0.7). I don't > know > how many sites are faster, lets assume the fastest are at about 0.5 seconds > (and > sites making 100 session accesses in one request surely do not belong in this > category). So if your average request duration is 500 millis, how important is > it for you to gain 0.00008 milliseconds, or even 0.8 milliseconds? In a microbenchmark, the JIT could be playing tricks on you, so I don't know ;) Obviously, one single read by itself is not going to cost much. Now multiply that by the number of reads you could be making during a single request, and also imagine what it could be if useless syncs were added in plenty other places inside the container "just to be safe". Syncs should be added wherever needed, but not more than needed. If you like microbenchmarks, you could compare (let's say with 1/3 writes, 2/3 reads): HashMap without sync, HashMap with syncs on writes, Hashtable, ConcurrentHashMap. I think there could be some more tuning being done for the attributes map (like setting a good initial size). Besides, this is a bit OT, and doesn't answer my question. I have just looked at two other popular servers source code, and some don't do any syncing for this, like Tomcat 5.0.x does. Overall, it means it's not portable, and the webapp really should plan on syncing on the session externally wherever needed. What I am willing to provide (this is the intent of the code in 5.5.x right now), by default, is making sure the HashMap cannot get corrupted, and that the infinite loop described in this report cannot occur. -- 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]
