An error then, if there's a control. A warning otherwise.
Daryl Olander wrote:
If it violates the contract, it's not a warning. (That assumes there is a
control in the shared flow)
On 1/18/06, Rich Feit <[EMAIL PROTECTED]> wrote:
I'm suggesting the warning for *any* public method that's not marked
synchronized. Why wouldn't this be sufficient?
Daryl Olander wrote:
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?
