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:26:57 GMT
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