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:34:13 GMT
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.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