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 Fri, 20 Jan 2006 01:44:11 GMT
I believe it is possible add/remove all controls from their container and
that the container could be found in the request.  I'm not sure the overhead
of this solution isn't much higher (time wise) and but it does save space.
Eddie and I talked though this, but I continue to believe this is a less
optimal solution.

On 1/19/06, Rich Feit <richfeit@gmail.com> wrote:
>
>
>
> Daryl Olander wrote:
> > In thinking about Eddie and Rich's objections, I've decided to provide
> the
> > Control Container as an abstraction.  It should actually be an pluggable
> > interceptor that sits inside the synchronized blocks.  I will abstract
> the
> > Container into a bean that could be configured (eventually) through
> Spring
> > and an interface defining the containers contract.  I will place the
> object
> > on Thread Local so that it can be accessed within a page flow for
> > programatic use (Eddie's concern).  It will also be possible in the
> future
> > for a "portal" to provide an implementation that can optimize for their
> use
> > cases (space/time tradeoff) and/or implement a different symantic
> (Rich's
> > concern).
> >
> Hmm... do we have any idea what kind of implementation in a portal would
> make the space issue OK, while still preserving the right behavior?
> > BTW, I haven't verified this, but I believe in thinking about it, we
> never
> > cleared controls out of the CCC once they were added so we were leaking
> all
> > controls in page flows instances beyond the life of the instance.  In
> > addition, I would guess this also made the unique id's unstable within
> > instance of the same page flow.  I'm going to verify this, but I suspect
> > this is a side affect of the current implementation.
> >
> Aren't we doing this currently in JavaControlUtils.uninitJavaControls
> (->destroyControl)?
> > On 1/19/06, Daryl Olander <dolander@gmail.com> wrote:
> >
> >> 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.0and
> >>>>>>>> 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