Re: Deadlock with NetUI NameService

[Carlin Rogers <ca...@gmail.com>]

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 <ca...@gmail.com> 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
>