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=43343>. 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=43343 ------- Additional Comments From [EMAIL PROTECTED] 2007-09-10 14:23 ------- No real reason I can find. We might want to use an instance variable as the lock just in case there are ever any other synchronized methods or sections added to the session where the entire session is locked. That would help if those synchronized session methods would need to be used by other threads and could be accessed even during passivation. I only find one place where the session itself is locked and that is in the expires method where a synchronized (this) is used. So, using the session itself would be OK for now, and it may logically work out to be the case that no other action should ever be able to actually be made or ever wanted on the session while it is being cached/passivated. I mentioned it could be used as the lock in the my description some where. So, at least for now, or always if deemed to always be wanted, I don't see any reason why it itself can not be the lock. -- 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]
