I've checked in code that solves this deadlock issue. I went ahead and created a different session scoped object as a mutex object for synchronizing the lazy initialization of the NameService object. The new mutex object is created via the HttpSessionMutexListener when the user session is created. The internal NetUI ServletUtils.getSessionMutex() method now takes an attribute name as a parameter for the mutex object to get from the session. Having the DSSH and the NameService use different objects resolves this deadlock issue below (and in BEEHIVE-1149).
Kind regards, Carlin On 10/19/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
Hey Eddie, Daryl, If either of you guys have a moment for some comments on this I'd greatly appreciate it... I have another thought. Could we have use a different object on the session as a mutex when creating the NameService? I don't think it essential that it is the same one being used by the DeferredSessionStorageHandler. This isn't an attribute that would be changed or removed from the session. This would allow us to maintain the synchronization around the lazy initialization of a NameService object to a session, rather than add one to every session during session creation (my proposed solution below). The only problem is that having a second mutex object implies either additional methods or some changes to what Eddie implemented in ServletUtils (where we assumed a single mutex with getSessionMutex()). What do you think? If you think it's best to use a different session mutex object, any thoughts on extending the current functionality from the ServletUtils? Thanks guys. I really do appreciate your thoughts. Carlin On 9/27/06, Carlin Rogers <[EMAIL PROTECTED]> wrote: > Eddie, Daryl, > > Hey, there's a thread deadlock problem in the interaction between the > NetUI DeferredSessionStorageHandler (DSSH) and a page flow that uses > the NameService (either in an action calling the > NameService.instance() or rendering a JSP with the netui:tree tag > using the XHR support. > > The problem occurs when two concurrent threads get the locks on the > session mutex object and page flow controller in reverse order. It can > occur in the following way: > > Thread A, Step 1 - PageFlowRequestProcessor.process() completes the > execute of the action and calls DSSH.applyChanges(). > Thread A, Step 2 - DSSH.applyChanges() gets a lock on the session mutex object. > > Thread B, Step 1 - PFRP.process() starts the process to execute the > action of a page flow. > Thread B, Step 2 - FlowController.execute() gets a lock on the page > flow controller object. > > Thread A, Step 3 - DSSH.applyChanges() tries to get lock on page flow > controller object (to apply changes from the request to the > session)... and waits. > > Thread B, Step 3 - The PageFlow action calls NameService.instance() > which in turn tries to get a lock on the session mutex object (to > ensure that only a single NameService object is created within a > specific user session)... and waits. > > ...in a deadlock now. > > > I was wondering if there was another way we could get the NameService > instance in the session such that we did not need the session mutex > object. Maybe we create and add it within > HttpSessionMutexListener.sessionCreated() or create another listener? > Other ideas? > > Thanks, > Carlin >
