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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
