Syncing the Session DOESN'T necessarily work. That's the point. When you have HTTP sessions, the AxisServlet creates a new AxisHttpSession object to wrap the HttpSession on every request. Locking on those objects is useless, because you really want to lock on the HttpSession. And in fact, I'm not 100% sure that locking on the HttpSession will even work, because I'm not sure what the servlet spec says about the uniqueness of HttpSession objects.
I still think we need Session.lock() and Session.release(), or at least Session.getLockableObject(), to allow for implementation differences. --Glen > I don't get it, the 1st sync will sync on the session - which > I believe > should be ok since that's will be the same session object > each time (based > on what scope you have - either serlvet session or > appSession). The 2nd > sync will sync on something that is local (or specific) to the service > itself (the String object I created). I don't see what the > problem is. I > never sync the hashtable - I sync the session and then I sync the lock > object. Man - I wish I could get on irc grrrr > -Dug > > > Glen Daniels <[EMAIL PROTECTED]> on 10/14/2002 05:57:54 PM > > Please respond to [EMAIL PROTECTED] > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > cc: > Subject: RE: sync > > > > > Locking the String or Object that is placed in the hashtable > > will do it > > since that is presistent across all threads - and it doesn't > > really matter > > which kind of Object it is - we just need something/anything > > to sync on. > > The problem is that you want only one thread to be the one > that creates the > sync-able thing, just like you want only one thread to create > the actual > service object. So the issue is with the outer sync (the one > on "session" > in your code). You can't sync "the hashtable" because you > don't know what > the underlying implementation of the Session object is. You > can't sync > "the Session" because there might be multiple ones wrapping the same > backend data store. So the only way I see it working is if > you can lock > the Session via the Session API itself. > > > There really isn't much to say about what's happening - we > > have one thread > > entering the sync block, calling the c'tor. In the c'tor it > > calls a web > > service on the same machine (but different service) so that > 2nd thread > > blocks on the sync block because we've locked the session (in > > this case the > > appSession) object. But like I said, with the current code > > you'll see the > > same deadlock (or really bad performance) if you have a > > hanging c'tor or > > really slow c'tor. > > Yup. I'll take a stab at fixing this. > > --Glen > > >
