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