> It looks like (according to cvs) you added the sync blocks in > JavaProvider and its cause use some problems. > I'm trying to understand why those sync blocks were added. > From what I can > tell they don't prevent multiple threads from clobbering each others > service object that's stored in the session data. It looks > like the sync > will prevent two threads from updating the service object > that's in the > session at the exact same time, but once the first one leaves > that block > the 2nd thread will clobber it and if the 1st one goes back > to get it it'll > get the wrong one. And in our case they're causing problems. > We have a > case where in the constructor for a service object it makes a > web service > call - which just happens to hit the same app server session > - so we block > - endlessly. What do you think about removing them?
(Doug and I discussed this on IRC, this msg is for the archives) Those sync blocks protect the session objects from being modified by more than one thread at a time. Your analysis above is incorrect, because the "if (obj == null)" inside the sync block prevents the second thread from making a new service object once the first thread has already added one to the session. We can't just remove them. My suggestion to Doug on IRC was to have the customer's object use the servicelifecycle method init() instead of the constructor, and we could move the call to init() outside the sync block. --Glen
