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. > >>> > >>> > >>> > >>> > >>> > > > > > > >
