Sorry, only one thread runs on create(), but they might both wait at the sync point.
On 1/16/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > > 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? > > >>> > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > >
