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-14 07:59 ------- (In reply to comment #73) > Fix it. Resolved my arse. And while you're at it, tell me what other areas of the "spec" I should be > misinterpreting, and working around in my code. Crying about a fork? Reading this, you practically > *deserve* one. Yes, unfortunately, you need to find yourself a replacement brain really fast so you could actually comprehend the issue. Syncing reads in addition to writes (which already prevents data corruption, and is done again in the entire 5.5 branch) provides very little, since your reads are going to be dirty anyway unless you sync yourself at the application level. Basically, the ConcurrentHashMap, which uses the same algorithm as the regular HashMap, just does an additional synced read if the result was null to the initial unsynced read. The problem should be solved soon, howver, and you'll be able to stop writing pointless rants, as the spec wording is going to be heavily changed. BTW, I am not crying about the Glassfish fork, I am mentionning that the way it was done was, as usual with companies doing forks, innappropriate. > its reputation as a stable platform Lol, most of the time, people (like you) say it's crap :D -- 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]
