Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of dolander@gmail.com designates
 66.249.82.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=BSBsnWDpDR8OTyeVnNo/s6qBD3Sgy7tW4XRjB8UI9paEjNuF1TiBDoHQTWOn4qMNRlLteLxaj7a5rarD9riJ7NYArfcUFYxRUSpC/B5FXQ6uOQ1q4PhxejO/ufjF76W4XAKJyTXwWap1twq/vZURo4et6OaD2Ym4JTC/iSpY3JQ=
Message-ID: <40f026540601191447q24cbe3d5we367f8918c1eeddf@mail.gmail.com>
Date: Thu, 19 Jan 2006 15:47:19 -0700
From: Daryl Olander <dolander@gmail.com>
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: Page Flow Runtime Control Container Design
In-Reply-To: <43D015E3.9050301@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_71632_1339388.1137710839202"
References: <40f026540601182015o68027356gb52293b5bb9b0e5c@mail.gmail.com>
	 <40f026540601191102r5d5384adv165d178195a853bb@mail.gmail.com>
	 <e9ac83540601191359r22a082cdoc965f080dbddfd9b@mail.gmail.com>
	 <43D0109B.9020105@gmail.com>
	 <40f026540601191426x6d187ab3ha9bc5a7dae69be28@mail.gmail.com>
	 <43D013E5.9030401@gmail.com>
	 <40f026540601191436r3dec998j2d9722e8be3f382c@mail.gmail.com>
	 <43D015E3.9050301@gmail.com>

------=_Part_71632_1339388.1137710839202
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 wa=
y
> >>>>> 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 bas=
e
> >>>>>> 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 containe=
r
> >>>>>>> implementation inside of the page flow runtime.  It is a summary
> of
> >>>>>>>
> >>>>>>>
> >>>> the
> >>>>
> >>>>
> >>>>>>> previous threads on this subject.  I'm currently in the process o=
f
> >>>>>>> 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 violate=
d
> >>>>>>>
> >> 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 contain=
s
> 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 creat=
e
> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
> >
>

------=_Part_71632_1339388.1137710839202--