I'm not sure this is legal. The contract between the control and container as far as I can tell is that we won't allow multiple threads into a control that is marked single threaded. At the minimum we would have to mark all methods that access a control (and a control couldn't be public or package-protected). This would involve code analysis of control usage or we would have to mark all methods synchronized. It seems to me the safest policy is either 1) mark them all synchonized if controls are present in the shared flow, or 2) not allow for single-threaded controls inside a shared flow by failing the compile.
We are already going to be forced to make some changes to try and support the proper request/response behavior and we will have to specifically define the life cycle for resource events. I don't believe there is any way to prevent resources from being shared between threads. I believe we are going to have to have a warning when compiling shared flow (and global app) about the resource issue. On 1/17/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > I think we might get far by putting a warning on any public or > package-protected method of a shared flow that's not marked with > 'synchronized'. What do you think? > > Daryl Olander wrote: > > Sorry, I meant that action execution is serialized but that other > threads > > can run in a shared flow when the action is executing. > > > > On 1/17/06, Daryl Olander <[EMAIL PROTECTED]> wrote: > > > >> Looks like the default for the thread policy on a control is single > >> threaded. As described in previous mails, Shared Flows and Global App > are > >> not single threaded. I believe that action execution is single > threaded, > >> but that mulitple threads can access state and call member method on a > >> shared flow while an action is running. The question I have when the > >> control JavaDoc specifies that the infrastructure must insure only a > single > >> thread will execute in a particular instance of that control at a time, > does > >> this mean the control container? If this is true, it seems to me we > are > >> going to have to throw exceptions when controls that are single > threaded are > >> created in either a Global App or Shared Flow. > >> > >> Does this match others understanding? > >> > >> > > > > >
