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.
