beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Control usage in Shared Flows
Date Tue, 17 Jan 2006 01:02:13 GMT
Right, it looks like we are violating the basic life cycle that a control
container should maintain in the page flow runtime.  I believe (Eddie/Chad
correct me here if I'm wrong), you need to keep a single thread in the
following life cycle on a ControlContainerContext
(beginContext->onAcquire->endContext (which calls onRelease)).  As it stands
at the moment, we are bleeding the request/response between page flow
threads, executing both in the same page flow and also in shared flows
because of how we initialize the PageFlowBeanContext.  It is initialized
once and stored in the session.  Because we can have multiple thread
executing multiple page flow in the same session at the same time, we don't
initialize and uninitialize the context correctly.  Each request pushs a new
RequestContext onto the PageFlowBeanContext (ServletBeanContext).  When the
control obtains the request it gets what ever is on the top of the stack.
In addition, if the control acquires things in the onAcquire event, these
resources are used on both threads.  Finally, because the uninitialize code
is not synchronized on the page flow instance, it can uninitialize while
another thread is making a call to the control (this is the bug that we are
seeing under load).

We obviously don't make any guarantee about shared flows or global app.
These are free threaded and we need to document that (Steve?)  These
controllers do run multiple threads, and therefore controls used there can
have multiple threads running through them.  It's beginning to look like we
are going to remove (deprecate) support for controls in both of these
because we can't actually guarantee the control container lifecycle.

At the moment, I just want to fix the way this works for page flow
controllers so we are doing the right thing.

I'm still really looking at the issue and there is a bunch I don't yet
understand (thus the questions :-)

Daryl

On 1/16/06, Rich Feit <richfeit@gmail.com> wrote:
>
> Short answer: I never thought there was *any* contract that would
> guarantee synchronization within the Controls tier -- the only guarantee
> is that you won't get multiple threads running in user code in the page
> flow controller.  If this is insufficient, we should discuss it.  In
> your example (synchronizing the entire request), it seems like we'd need
> to be synchronizing *across* forwarded requests (to get both the action
> and the page render in one block, for instance), which seems sketchy.
>
> Am I understanding your question here?
>
> Daryl Olander wrote:
>
> >I guess, I'm trying to understand what the contract the control container
> >(the page flow runtime) has with respect to controls used there.  For
> >example, should we be synchronizing the entire request against the
> current
> >page flow so that the request/response and resource lifetimes are
> enforced
> >for the request?  Right now this isn't how the page flow runtime works.
> >
> >On 1/16/06, Rich Feit <richfeit@gmail.com> wrote:
> >
> >
> >>I'm actually not the best person to answer questions about the threading
> >>model for controls themselves, but as to shared flows, you're right --
> >>you can get two threads into a shared flow when accessing it directly
> >>from a page flow.  This should be mentioned somewhere in the docs, but
> >>it isn't.  Basically, I think it's theoretically possible to synchronize
> >>on every referenced shared flow when entering a page flow (doing it in
> >>some deterministic order to avoid deadlock issues when hitting multiple
> >>page flows that reference the same set of shared flows), but the
> >>performance impact always seemed high.  What do you think?
> >>
> >>
> >>Daryl Olander wrote:
> >>
> >>
> >>
> >>>Rich, if you could comment on this I'd appreciate it.
> >>>
> >>>I'm trying to understand the contract we hold with controls.  I believe
> >>>
> >>>
> >>that
> >>
> >>
> >>>we say that controls are single threaded.  The issue is what do we say
> >>>
> >>>
> >>about
> >>
> >>
> >>>the scope of the resource events (onAcquire and onRelease).  Within a
> >>>
> >>>
> >>page
> >>
> >>
> >>>flow, the onAcquire is raised on the first call to a control method.
> >>>onRelease is then called at the end of the request processor and in the
> >>>filters.   onAcquire can be called multiple times but is called on the
> >>>control only once until the onRelease event is called.
> >>>
> >>>I believe that this results in a pretty fundamental design problem
> inside
> >>>
> >>>
> >>of
> >>
> >>
> >>>shared flows.  If there are multiple threads in the same session,
> running
> >>>against different page flows instances, they may share shared
> flows.  As
> >>>
> >>>
> >>far
> >>
> >>
> >>>as I understand it, this means
> >>>1) Shared flows can have two threads running inside them at a time (?)
> >>>2) That the onAquire/onRelease are tied to on request but shared
> between
> >>>
> >>>
> >>two
> >>
> >>
> >>>requests.  (The result is that you can share the database connection in
> a
> >>>database control against two requests)
> >>>
> >>>Seems like you end up with something like this:
> >>>1) Thread 1 calls a method on a control defined in a shared flow which
> >>>
> >>>
> >>calls
> >>
> >>
> >>>onAcquire() on the first thread (and associates the request/response in
> >>>
> >>>
> >>the
> >>
> >>
> >>>bean context with Thread 1's request.
> >>>2) Thread 2 enters a second page flow and calls a control on the same
> >>>
> >>>
> >>shared
> >>
> >>
> >>>flow instance.  onAcquire isn't called and the request from thread 1 is
> >>>still active in the controls bean context
> >>>3) Thread 1 exists the action and calls onRelease() on the shared flow
> >>>4) Thread 2 calls another method on the control.  Now onAcquire() is
> >>>
> >>>
> >>called
> >>
> >>
> >>>and the request from Thread 2 is used in the bean context
> >>>5) Thread 2 exists the action and calls onRelase() on the shared flow
> >>>
> >>>Rich can you confirm this understanding?
> >>>
> >>>Thanks
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>

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