--- Wade Chandler <[EMAIL PROTECTED]> wrote: > --- "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? Ok, so after I wrote that I checked the latest source....it is a Hashtable. When did the behaviour change that a null attribute could not be used. I could have swore I remember using null attributes in sessions...oh well, the way it is handled in setAttribute works well. Remove it so you can always check to see if it is set or not with a getAttribute call. So yeah, that should do it. I guess I'll go ahead and check the SessionContext as well.
... Wade --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
