Major Description
Here's a scenario that will cause a deadlock in NetUI for concurrent requests to a page flow controller action and a JSP for that controller that includes another JSP for the same controller.
The issue is a difference in the lock order introduced by the JSP include.
The request to an action ("begin.do") may execute, forward to the JSP, then after the forward to the JSP has been completed, the PageFlowRequestProcessor will call the DeferredSessionStorageHandler (DSSH) method applyChanges(). It will commit any session-scoped changes that were stored in the request. DSSH first gets a lock on a NetUI session mutex object, then get a lock on the current page flow.
However, the direct request to the JSP that includes another JSP will have a reversed lock order. In general, the PageFlowPageFilter (PFPF) first gets a lock on the current page flow the runs the page (chain.doFilter()). After the page has run the page flow lock is released. If the request is not a page flow forwarded request, then it calls the DSSH.applyChanges() as above. The deadlock occurs with a direct request to a JSP that includes another JSP because the lock order will be page flow object then session mutex object.
The PFPF has a lock on the current page flow and processes the page with the include. The RequestDispatcher.include() goes through the PFPF again (same thread, so no wait on the synchronized lock on the page flow) and processes the included JSP. Then the PFPF call to DSSH.applyChanges() gets a lock on the NetUI session mutex... a different order!
Here's an outline of an example page flow and JSP that might clarify my description above.
page flow implemented...
src/
deadlock/
Controller.java ("begin.do" forwards to index.jsp)
web/
deadlock/
index.jsp (includes more.jsp)
more.jsp
The scenario goes like this...
- Thread A is request to /webappcontext/deadlock/begin.do
- Thread B is a request to /webappcontext/deadlock/index.jsp
A: PageFlowRequestProcessor execute action
A: call DSSH.applyChanges()
A: get lock on session mutex
B: PageFlowPageFilter lock on current page flow
B: chain.doFilter() process requested JPF
A: try to get lock on current page flow (WAIT)
B: RequestDispatcher.include() another JPF
B: PageFlowPageFilter lock on current page flow (no wait)
B: chain.doFilter() process included JPF
B: call DSSH.applyChanges()
B: try to get lock on session mutex (WAIT)
and now in deadlock!