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 17:51 ------- (In reply to comment #43) > When would anyone want to use a "threadUnsafe" session set/getAttribute? > As we have seen, NOT syncing this causes hangs - so therefore developer > needs to do this (if he uses these methods). Wouldn't it make more sense to > just sync it further down in tomcat, as suggested here, rather than needing > to sync the whole method every single time you use this in your code? One possible case is for a really simple dumb cache: where you expect the result to be present in the session on every time except the first (eg where the read:write ratio is 10000:1). In such a case, if the get is unsynchronized, it's safe to say: Object cached = session.get(key); if (cached == null) { synchronized (session) { cached = session.get(key); if (cached == null) { cached = "blah"; session.put(key, cached); } } } I understand there is potential waste doing two gets (one in and one out of synchronized block), but this only gets executed on the first hit, so decreases in significance as the read:write ratio goes up. Anyway - that's one case I've found where an un-threadsafe get helps performance wise, especially on lower spec machines short on memory (only through subjective observations though - don't have any numbers). -- 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]
