--- "Duan, Nick" <[EMAIL PROTECTED]> wrote: > Well, when I was mentioning the term user session, I > was discussing from > a threading/transaction perspective, not from the > servlet object > perspective. It is the worker thread that > represents a active user > session and accesses both the session and the > servlet object (if we want > to be precise). > > Chuck was right. It is possible to have one client > (single browser) to > start two concurrent sessions at the same time, both > eligible to access > the same HttpSession object. Therefore, it looks > like synchronization > is necessary from the spec. However, the spec does > not define how > HttpSession should be implemented (it's just an > interface). In fact, > the session attributes were implemented as a > Hashtable in tomcat, not a > Hashmap (just double checked the latest 5.5.15 src > of tomcat). As we > all know, Hashtable already has thread sync built > in. So that's why > additional synchronization on HttpSession in tomcat > is unnecessary. > > ND I don't know about 5.5.15, but 5.5.9 used HashMap. The synchronization of the session object was an issue which caused other issues and is why there should now be synchronization on the reading as well as writing session attributes. There was a huge discussion on this on the list as well as a bug associated with it which could cause finite dead locks in Tomcat if access made the session resize while it were being read (should be able to find it in bugzilla...bugzilla was still being used). Session has to be synchronized anyways, so regardless of misintrepretation/correct interpretation of the specification arguments it would make sense for these calls to be synchronized by what ever server is implementing the specification. I'm saying: If all developers have to synchronize access to all session access then would it not make sense for things to be synchronized as they currently are...at the server level? All scopes which would need synchronization should really be handled at the server level (application and session).
The tomcat source code should be synchronizing these things now. At the time it wasn't talked about, but the application level scope was not being synchronized when I looked through the source code when the synchronization bug mentioned above was being discussed. I don't know if this has changed or not (I was hoping ... considering the needless long overly exhaustive discussion that had to occur to get an obvious bug changed back to the correct behaviour...it was once synchronized correctly before it was broken....that the other pieces would be seen and fixed as well as they would cause the same dead lock behaviour as session access could depending on what happened when the application scope was accessed does a read occur when a write occurs or a write at certain points in the resize.). Just to clarify now before a discussion starts again on this topic: It matters these things are taken care of at the server level in one place or another as JSP/EL are hard to synchronize without breaking their use case (not to use java code within them). I mean, if someone knows how to synchronize access to the session or application scopes (use that term to represent accessing the session from all other places and tags it can be accessed) when using EL or setting/getting a bean in a JSP without a specialized tag library or wrapping in java code then please share, but I think I'm asking an unanswerable quesiton ;-) I wouldn't imagine that the source code is using Hashtable as Hashtable does not allow null values, and would have changed the currently used session access. Were you looking at the file: $TOMCAT_SRC/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java in your source? Wade --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
