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:47:19 GMT
Is there an easy way to tell how big an object is?  (The space is mostly in
the Bean base classes that are part of Java.Beans)

On 1/19/06, Rich Feit <richfeit@gmail.com> wrote:
>
> Ah right, it's not just for requests that go to shared flows.  Well, I
> think this will all work.  My biggest concern is the space requirements
> of the CCC, multiplied if this happens in a portal.  It's just something
> we should look at.  Do we know how big the CCC will be?
>
> Daryl Olander wrote:
> > 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