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
