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 Runtime Control Container Design
Date Thu, 19 Jan 2006 22:20:11 GMT
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?
    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?


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
View raw message