No that the threads can swap their position through the stages. 1) Thread 1 executes 1 (and goes into a wait) 2) Thread 2 executes 1 and 2 (basically Thread 2 beats Thread 1 to the synchronization for beginAction/Action/afterAction) 3) Thread 1 executes 2 and 3 (Thread 2 waits and Thread 1 then executes the final two synchronized blocks) 4) Thread 2 executes 3 (Thread 2 now gets the final synchronization block)
On 1/16/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > Quick question -- in your example, do you mean that both Thread 1 and > Thread 2 run onCreate() on the same controller instance? That should > never happen, but if you're seeing that or if you're assuming that, can > you confirm it? > > Daryl Olander wrote: > > >Let me see if I understand this, > > > >Looks like there are a few thing that synchronize on the current page > flow: > >1) The onCreate is synchronized > >2) The beginAction, Action, afterAction > >3) The JSP rendering > > > >(There may be others but these are the important ones) > > > >So outside of these synchronized sections, we create things like the > >ServletBeanContext that has reference to the request and > response. Further, > >the resource events can occur in any of the three spots above, but we can > >swap threads through this: > > > >1) Thread 1 executes 1 > >2) Thread 2 executes 1 and 2 > >3) Thread 1 executes 2 and 3 > >4) Thread 2 executes 3 > > > >As far as I can tell, the result is that any resources acquired in the > >onAcquire() method will then be used by both threads until one of them > hits > >the uninitializeControls method and frees the contexts. > > > >Does this agree with your understanding? > > > >On 1/16/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > > > > >>Hey Daryl, > >> > >>We should never allow two threads into user code at the same time, > >>although you could potentially get into a situation where you're > >>interleaving calls to actions and property getters. We synchronize the > >>page rendering on the controller instance; see PageFlowPageFilter:284. > >>Let me know if you see any issues with this, though. > >> > >>Rich > >> > >>Daryl Olander wrote: > >> > >> > >> > >>>Rich, I'd love some confirmation of the following if you can, > >>> > >>>I'm in the process of looking at some issue with the BeanContext and > >>> > >>> > >>Control > >> > >> > >>>use in NetUI and I have a question about threading. I believe that we > >>> > >>> > >>make > >> > >> > >>>the statement that PageFlow are single threaded. The issue is that I > >>>believe we in fact allow more than one thread into a page flow. Here > is > >>> > >>> > >>an > >> > >> > >>>example of where I think it can happen. > >>> > >>>If you have a set of frames on a page, all making requests to the same > >>> > >>> > >>page > >> > >> > >>>flow, they will serialize access to the actions in the page flow. When > >>> > >>> > >>the > >> > >> > >>>first thread finishes the action and forwards to a JSP, the second > thread > >>> > >>> > >>is > >> > >> > >>>allowed access to the page flow. This is the reason we say things are > >>>single threaded. The problem is that if the JSP takes a while to run > and > >>> > >>> > >>it > >> > >> > >>>databinds to properties on the page flow you can have multiple threads > >>>running through the page flow. The first thread is calling property > >>> > >>> > >>getters > >> > >> > >>>while rendering the JSP and the second thread is running an > action. This > >>> > >>> > >>is > >> > >> > >>>actually not uncommon if the property being accessed calls a control > that > >>>accesses an external resource like a database. > >>> > >>>Rich, can you comment on this? Is there something else that prevents > >>>multiple threads from entering a page flow? > >>> > >>> > >>> > >>> > >>> > > > > > > >
