beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Multiple Threads inside a Page Flow instance?
Date Tue, 17 Jan 2006 00:39:31 GMT
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 <richfeit@gmail.com> 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 <richfeit@gmail.com> 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?
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message