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
