beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Page Flow Control Container Fix
Date Tue, 17 Jan 2006 20:48:00 GMT
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 thread
>may be running in a control method.  (This is the problem that originally
>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 on
>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 page
>flow.  I believe there are three blocks of code that are synchronized and
>provide user code access to controls in a page flow, the onCreate, the
>beforeAction/Action/afterAction, and JSP rendering.  This means we now do 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 during
>JSP rendering for example).
>
>I'm proposing to send out the diff later today for review of this portion 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.
>
>  
>

Mime
View raw message