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.197 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=MaEXh5vGxSEvOfHaSzhYUnP2J3l+ReeNQgs9Bk0naEsx8z24B2KJZwPsRvpnifhWuiL6StFz6e9kJ1EqTg9aoEuaZnY2xOXD3k94MDxxSm5UC0x/uxVXKx27BIQAzW/FAgB9ZHxH4+a2FdwwYV8I0hU2faJJdRnv61pM+s/GHcU=
Message-ID: <40f026540601171302o5e15fd4s9c82d0dbe470ee69@mail.gmail.com>
Date: Tue, 17 Jan 2006 14:02:37 -0700
From: Daryl Olander <dolander@gmail.com>
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: Page Flow Control Container Fix
In-Reply-To: <43CD5800.4000506@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_39655_27498518.1137531757536"
References: <40f026540601171021n7300f954w2e7487fb151a0817@mail.gmail.com>
	 <43CD5800.4000506@gmail.com>

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

Yes there is one per instance.  The problem with scoping it to the request
you then have to call the JavaControlUtils.initJavaControls on each request
to make sure the controls point to their context (this is currently done in
create).

I don't believe we can do it on the request boundary, but would have to do
it at each of the synchronization blocks.

On 1/17/06, Rich Feit <richfeit@gmail.com> wrote:
>
> One question I have is about session size.  The reason that
> FlowController itself wasn't a Controls context originally was that it
> would have magnified the size of the controller instance in the session
> (there's a lot of state in the base context classes).  With this change,
> is there now a PageFlowBeanContext per FlowController instance?  If so,
> this could increase the session size by a lot, in any case where there's
> more than one FlowController in the session (e.g., nesting or multiple
> browser windows, but it would be particularly dramatic in a portal).
>
> Am I understanding correctly?
>
> If so, would it be possible instead to scope the PageFlowBeanContext
> into the request?  This seems similar to what Chad did on the
> ControlFilter side (disabling the ability to store the context in the
> session).  I'd have the same question here that I would there;
> basically, is it OK to have a control that lives longer than a context
> it gets put into?  But if it *is* OK, then this might be a good
> alternative.
>
> Rich
>
> Daryl Olander wrote:
>
> >I have the first part of the page flow Control Container issue fixed and
> >passing BVTs.
> >
> >There are two basic problems with the current implementation of the
> control
> >container support inside the page flow runtime.  The first issue is that
> we
> >don't guarantee that beginContext->onAcquire->endContext->onRelease will
> run
> >on only a single thread (request).  The result is that any resources
> >acquired in the onAcquire() event by a control can be shared by threads
> in
> >multiple requests and that we at time call onRelease while another threa=
d
> >may be running in a control method.  (This is the problem that originall=
y
> >was seen.)  The second issue, is that the same request/response are also
> >visible on two different threads.  In this problem the last thread pushs
> the
> >request/response onto a stack maintained by the ServletBeanContext.  The
> >context is stored in the session, meaning all controls using the context
> >actually just see the request/response that is on the top of the stack.
> >
> >My fix involves a couple of simple changes.  At the moment, I'm ignoring
> the
> >faces backing bean object which is the second part of this fix and not
> yet
> >finished.  For my change I did the following:
> >
> >1) I scope the PageFlowBeanContext (ServletBeanContext,
> >ControlContainerContext) to a FlowController.   Because we synchronize o=
n
> >the current page flow and the life time of the controls is the page flow
> >instance, it makes sense that the ControlContainerContext is also scoped
> to
> >the page flow.
> >
> >2) I then move the beginContext/endContext (initialization/termination)
> code
> >into the synchronization blocks that prevent multiple threads into a pag=
e
> >flow.  I believe there are three blocks of code that are synchronized an=
d
> >provide user code access to controls in a page flow, the onCreate, the
> >beforeAction/Action/afterAction, and JSP rendering.  This means we now d=
o
> a
> >beginContext/endContext three times for a new page flow request. We also
> >create a ControlContainerContext when a page flow is created.  It also
> >insures that the container guarantees that the control life cycle above
> is
> >enforced.
> >
> >I've passed the BVTs, but there are very few controls tests.  I've added
> a
> >few tests that were not covered (like not calling a control method durin=
g
> >JSP rendering for example).
> >
> >I'm proposing to send out the diff later today for review of this portio=
n
> of
> >the change and I will then check this in tomorrow if there are no
> >objections.  This is a pretty risky change because I'm not completely
> >familiar with the page flow runtime and the controls life cycle.  Please
> >review this fix and this message.
> >
> >Thanks
> >
> >BTW, this fix simply fixes the page flow problem.  This exact problem
> still
> >exists in shared flows and global app.  At the moment, it looks like we
> >can't solve this problem there (still more thinking to be done).  The
> result
> >is that we may end up deprecating the use of Controls in shared flow and
> >global app.
> >
> >
> >
>

------=_Part_39655_27498518.1137531757536--