Is there an easy way to tell how big an object is? (The space is mostly in the Bean base classes that are part of Java.Beans)
On 1/19/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > Ah right, it's not just for requests that go to shared flows. Well, I > think this will all work. My biggest concern is the space requirements > of the CCC, multiplied if this happens in a portal. It's just something > we should look at. Do we know how big the CCC will be? > > Daryl Olander wrote: > > No, because you have to get access to the "shared flow" lock before you > can > > enter user code in onCreate, action invocation and JSP rendering. Thus > the > > statement that we have serialization points for multiple threads within > a > > session. > > > > On 1/19/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > > >> OK... one other thing: is there still a hole here for direct access to > >> the shared flow through a reference in the page flow? > >> > >> Daryl Olander wrote: > >> > >>> On 1/19/06, Rich Feit <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> I can't tell the difference between this and Daryl's option #2, so I > >>>> guess I agree with both of you. :) > >>>> > >>>> Daryl, I have just a few questions: > >>>> 1) The Lock object is session-scoped, right? > >>>> > >>>> > >>> Right... > >>> > >>> 2) Are you saying that you'd call the CCC's begin/end-context > >>> > >>> > >>>> methods around *every* point that runs user code? So within a given > >>>> request, you'd potentially do this around onCreate(), the action > >>>> invocation, and JSP rendering? > >>>> > >>>> > >>> Exactly...These are the three points where we do this. For the > average > >>> request, it would be just the action invocation and JSP rendering. > >>> > >>> Eddie O'Neil wrote: > >>> > >>> > >>>>> Hm...this is a tricky issue. I'd actually go a different route > and > >>>>> do two things: > >>>>> > >>>>> 1) only create the CCC for each page flow in the presence of > @Control > >>>>> annotations > >>>>> 2) explain how to write code to create a CCC and drive it through > its > >>>>> > >>>>> > >>>> lifecycle > >>>> > >>>> > >>>>> This is how the JUnit test container works for Controls -- you can > use > >>>>> the ControlsTestCase base class or write code that calls utilities > >>>>> that provide the CCC and drive it through its lifecycle. > >>>>> > >>>>> Seems like this provides the best of both worlds -- uses metadata > to > >>>>> decide when controls are used but gives application developers a way > >>>>> to use controls programmatically without having a Controls-related > API > >>>>> exposed on the Page Flow base class. > >>>>> > >>>>> Yes, there's a compatibility issue *if* you used JPF from 1.0 and > >>>>> declared controls programmatically, but that's probably not very > >>>>> common. > >>>>> > >>>>> Eddie > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 1/19/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> So it turns out, there is indeed a test that creates a control > >>>>>> programmatically in a page flow. This seems to leave us with two > >>>>>> alternatives > >>>>>> 1) we always create the CCC for every page flow > >>>>>> 2) we add an ensureControlContainerContextExists() API (to the base > >>>>>> PageFlowController) to make sure that it is created and > initialized. > >>>>>> > >>>>>> I lean toward 2 because I think this use case is rare. It is a > >>>>>> > >>>>>> > >>>> backward > >>>> > >>>> > >>>>>> compatibility issue with our 1.0 release. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> On 1/18/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> This mail summarizes the proposed design for the Control container > >>>>>>> implementation inside of the page flow runtime. It is a summary > of > >>>>>>> > >>>>>>> > >>>> the > >>>> > >>>> > >>>>>>> previous threads on this subject. I'm currently in the process of > >>>>>>> implementing this solution and believe it solves the sets of > issues > >>>>>>> > >>>>>>> > >>>> brought > >>>> > >>>> > >>>>>>> up in those emails. I would really like review of this solution > and > >>>>>>> comments/questions so we can be sure this works. > >>>>>>> > >>>>>>> There are two basic requirements of the Control container > >>>>>>> 1) All controls have only a single thread in them at a time > (Single > >>>>>>> Threaded) > >>>>>>> 2) The resources a control may acquire are only used for a single > >>>>>>> request. It is ok if the resources are acquired more than once > for > >>>>>>> > >> a > >> > >>>> single > >>>> > >>>> > >>>>>>> request. > >>>>>>> > >>>>>>> In today's implementation, both of these requirements are violated > >>>>>>> > >> by > >> > >>>>>>> standard page flows and shared flows (and global app). These > issues > >>>>>>> > >>>>>>> > >>>> are > >>>> > >>>> > >>>>>>> summarized in the previous threads on this subject. > >>>>>>> > >>>>>>> The proposed solution is this, > >>>>>>> > >>>>>>> For a standard page flow (normal page flow, singleton page flow > and > >>>>>>> > >>>>>>> > >>>> nested > >>>> > >>>> > >>>>>>> page flow), they have a ControlContainerContext (CCC) for the > >>>>>>> > >> controls > >> > >>>> that > >>>> > >>>> > >>>>>>> they contain. The CCC is only allocated if the page flow contains > a > >>>>>>> control. We will have to probably add an API someplace to create > >>>>>>> > >> this > >> > >>>> if a > >>>> > >>>> > >>>>>>> user wants to create a control programmatically. > >>>>>>> > >>>>>>> For all Shared flows and global app, they will share a single CCC. > >>>>>>> > >>>>>>> During a request, there are three possible synchronization points > >>>>>>> > >>>>>>> > >>>> where > >>>> > >>>> > >>>>>>> user code can run and call methods on controls > >>>>>>> 1) during onCreate when a page flow is created > >>>>>>> 2) during the beforeAction/Action/afterAction cycle > >>>>>>> 3) during JSP rendering > >>>>>>> > >>>>>>> During any of these, code may access a shared flow and interact > with > >>>>>>> controls. For most page flow requests only 2 and 3 are run. > >>>>>>> > >>>>>>> For a the standard page flows, these synchronization points create > a > >>>>>>> single threaded model. For the standard page flow CCC, we will > run > >>>>>>> > >>>>>>> > >>>> the > >>>> > >>>> > >>>>>>> beginContext, endContext events which activate the resource > >>>>>>> > >>>>>>> > >>>> lifecycle. This > >>>> > >>>> > >>>>>>> is sufficient to guarantee 1 and 2. > >>>>>>> > >>>>>>> For shared flows, we still have issues if multiple threads are > >>>>>>> > >> running > >> > >>>>>>> through the session. To solve this we will do this, > >>>>>>> 1) We will create a single Lock object that must be obtained in > the > >>>>>>> synchronization points before we can proceed. > >>>>>>> 2) Once the lock is obtained, we will run beginContext on the > shared > >>>>>>> > >>>>>>> > >>>> flows > >>>> > >>>> > >>>>>>> CCC. > >>>>>>> 3) We will run the normal user code > >>>>>>> 4) We will then run the endContext on the shared flows CCC > >>>>>>> 5) We will release the lock > >>>>>>> > >>>>>>> Rich, please verify this will work... > >>>>>>> > >>>>>>> The result of this, is that we will serialize threads within a > >>>>>>> > >> session > >> > >>>>>>> through these synchronization points. The result is that shared > >>>>>>> > >> flows > >> > >>>> will > >>>> > >>>> > >>>>>>> become single threaded (requirement 1 above) and because we run > the > >>>>>>> beginContext/endContext that satisfies 2 above. > >>>>>>> > >>>>>>> There is a bit more overhead to this solution because there will > >>>>>>> > >>>>>>> > >>>> typically > >>>> > >>>> > >>>>>>> be two CCC objects active at one time. Deep nesting and > singletons > >>>>>>> > >>>>>>> > >>>> will add > >>>> > >>>> > >>>>>>> more. The CCC is only created for page flows that have > >>>>>>> > >> controls. The > >> > >>>>>>> benefits is that the CCC objects match the lifetime of the > controls > >>>>>>> > >>>>>>> > >>>> that > >>>> > >>>> > >>>>>>> they contain. > >>>>>>> > >>>>>>> Please review this and send comments. > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> Daryl > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>> > > > > >
