> 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
