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 Wed, 18 Jan 2006 01:07:03 GMT
We wouldn't infer it -- I mean it would be support that is enabled 
per-control explicitly.

Daryl Olander wrote:
> how do we know which are which?
>
> On 1/17/06, Rich Feit <richfeit@gmail.com> wrote:
>   
>> What I'm asking is whether we could separate out support for
>> request-specific contexts, for use with controls that get resources that
>> are tied to a specific request (and *not* ones that merely use the
>> request as a path to get a ServletContext-scoped object).
>>
>> Daryl Olander wrote:
>>     
>>> It's obviously control dependent.  For example, in the database control
>>>       
>> the
>>     
>>> connection is acquired in the onAcquire method.  You can invision other
>>> controls that could hold something like a disconnected dataset that you
>>>       
>> can
>>     
>>> share between requests for some reason.  It's really about the control.
>>>
>>> On 1/17/06, Rich Feit <richfeit@gmail.com> wrote:
>>>
>>>       
>>>> That's true, and I see how that could cause perf issues.  I do think
>>>> that having one context per controller instance could create massive
>>>> user sessions, though -- it would be worth looking into.
>>>>
>>>> One other basic question I have is about use case.  In general, what
>>>>         
>> are
>>     
>>>> you acquiring in onAcquire that actually is scoped to a particular
>>>> request?  Is it possible that we could separate out that kind of
>>>> support, to avoid having a separate context per FlowController?
>>>>
>>>> An alternative would be to make the base context *much* more
>>>>         
>> lightweight
>>     
>>>> than it is today (or than it was when I looked at it last).
>>>>
>>>> Rich
>>>>
>>>> Daryl Olander wrote:
>>>>
>>>>
>>>>         
>>>>> 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
>>>>>>>
>>>>>>>               
>>>> 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