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:42:43 GMT
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 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