beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: Page Flow Runtime Control Container Design
Date Thu, 19 Jan 2006 22:36:32 GMT
No, because you have to get access to the "shared flow" lock before you can
enter user code in onCreate, action invocation and JSP rendering.  Thus the
statement that we have serialization points for multiple threads within a
session.

On 1/19/06, Rich Feit <richfeit@gmail.com> wrote:
>
> OK... one other thing: is there still a hole here for direct access to
> the shared flow through a reference in the page flow?
>
> Daryl Olander wrote:
> > On 1/19/06, Rich Feit <richfeit@gmail.com> wrote:
> >
> >> I can't tell the difference between this and Daryl's option #2, so I
> >> guess I agree with both of you.  :)
> >>
> >> Daryl, I have just a few questions:
> >>     1) The Lock object is session-scoped, right?
> >>
> >
> >
> > Right...
> >
> >     2) Are you saying that you'd call the CCC's begin/end-context
> >
> >> methods around *every* point that runs user code?  So within a given
> >> request, you'd potentially do this around onCreate(), the action
> >> invocation, and JSP rendering?
> >>
> >
> >
> > Exactly...These are the three points where we do this.  For the average
> > request, it would be just the action invocation and JSP rendering.
> >
> > Eddie O'Neil wrote:
> >
> >>>   Hm...this is a tricky issue.  I'd actually go a different route and
> >>> do two things:
> >>>
> >>> 1) only create the CCC for each page flow in the presence of @Control
> >>> annotations
> >>> 2) explain how to write code to create a CCC and drive it through its
> >>>
> >> lifecycle
> >>
> >>> This is how the JUnit test container works for Controls -- you can use
> >>> the ControlsTestCase base class or write code that calls utilities
> >>> that provide the CCC and drive it through its lifecycle.
> >>>
> >>>   Seems like this provides the best of both worlds -- uses metadata to
> >>> decide when controls are used but gives application developers a way
> >>> to use controls programmatically without having a Controls-related API
> >>> exposed on the Page Flow base class.
> >>>
> >>>   Yes, there's a compatibility issue *if* you used JPF from 1.0 and
> >>> declared controls programmatically, but that's probably not very
> >>> common.
> >>>
> >>> Eddie
> >>>
> >>>
> >>>
> >>>
> >>> On 1/19/06, Daryl Olander <dolander@gmail.com> wrote:
> >>>
> >>>
> >>>> So it turns out, there is indeed a test that creates a control
> >>>> programmatically in a page flow.  This seems to leave us with two
> >>>> alternatives
> >>>> 1) we always create the CCC for every page flow
> >>>> 2) we add an ensureControlContainerContextExists() API (to the base
> >>>> PageFlowController) to make sure that it is created and initialized.
> >>>>
> >>>> I lean toward 2 because I think this use case is rare.  It is a
> >>>>
> >> backward
> >>
> >>>> compatibility issue with our 1.0 release.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> On 1/18/06, Daryl Olander <dolander@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> This mail summarizes the proposed design for the Control container
> >>>>> implementation inside of the page flow runtime.  It is a summary
of
> >>>>>
> >> the
> >>
> >>>>> previous threads on this subject.  I'm currently in the process
of
> >>>>> implementing this solution and believe it solves the sets of issues
> >>>>>
> >> brought
> >>
> >>>>> up in those emails.  I would really like review of this solution
and
> >>>>> comments/questions so we can be sure this works.
> >>>>>
> >>>>> There are two basic requirements of the Control container
> >>>>> 1) All controls have only a single thread in them at a time (Single
> >>>>> Threaded)
> >>>>> 2) The resources a control may acquire are only used for a single
> >>>>> request.  It is ok if the resources are acquired more than once
for
> a
> >>>>>
> >> single
> >>
> >>>>> request.
> >>>>>
> >>>>> In today's implementation, both of these requirements are violated
> by
> >>>>> standard page flows and shared flows (and global app).  These issues
> >>>>>
> >> are
> >>
> >>>>> summarized in the previous threads on this subject.
> >>>>>
> >>>>> The proposed solution is this,
> >>>>>
> >>>>> For a standard page flow (normal page flow, singleton page flow
and
> >>>>>
> >> nested
> >>
> >>>>> page flow), they have a ControlContainerContext (CCC) for the
> controls
> >>>>>
> >> that
> >>
> >>>>> they contain.  The CCC is only allocated if the page flow contains
a
> >>>>> control.  We will have to probably add an API someplace to create
> this
> >>>>>
> >> if a
> >>
> >>>>> user wants to create a control programmatically.
> >>>>>
> >>>>> For all Shared flows and global app, they will share a single CCC.
> >>>>>
> >>>>> During a request, there are three possible synchronization points
> >>>>>
> >> where
> >>
> >>>>> user code can run and call methods on controls
> >>>>> 1) during onCreate when a page flow is created
> >>>>> 2) during the beforeAction/Action/afterAction cycle
> >>>>> 3) during JSP rendering
> >>>>>
> >>>>> During any of these, code may access a shared flow and interact
with
> >>>>> controls. For most page flow requests only 2 and 3 are run.
> >>>>>
> >>>>> For a the standard page flows, these synchronization points create
a
> >>>>> single threaded model.  For the standard page flow CCC, we will
run
> >>>>>
> >> the
> >>
> >>>>> beginContext, endContext events which activate the resource
> >>>>>
> >> lifecycle.  This
> >>
> >>>>> is sufficient to guarantee 1 and 2.
> >>>>>
> >>>>> For shared flows, we still have issues if multiple threads are
> running
> >>>>> through the session.  To solve this we will do this,
> >>>>> 1)  We will create a single Lock object that must be obtained in
the
> >>>>> synchronization points before we can proceed.
> >>>>> 2) Once the lock is obtained, we will run beginContext on the shared
> >>>>>
> >> flows
> >>
> >>>>> CCC.
> >>>>> 3) We will run the normal user code
> >>>>> 4) We will then run the endContext on the shared flows CCC
> >>>>> 5) We will release the lock
> >>>>>
> >>>>> Rich, please verify this will work...
> >>>>>
> >>>>> The result of this, is that we will serialize threads within a
> session
> >>>>> through these synchronization points.  The result is that shared
> flows
> >>>>>
> >> will
> >>
> >>>>> become single threaded (requirement 1 above) and because we run
the
> >>>>> beginContext/endContext that satisfies 2 above.
> >>>>>
> >>>>> There is a bit more overhead to this solution because there will
> >>>>>
> >> typically
> >>
> >>>>> be two CCC objects active at one time.  Deep nesting and singletons
> >>>>>
> >> will add
> >>
> >>>>> more.  The CCC is only created for page flows that have
> controls.  The
> >>>>> benefits is that the CCC objects match the lifetime of the controls
> >>>>>
> >> that
> >>
> >>>>> they contain.
> >>>>>
> >>>>> Please review this and send comments.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Daryl
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >
>

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