Short answer: I never thought there was *any* contract that would
guarantee synchronization within the Controls tier -- the only guarantee
is that you won't get multiple threads running in user code in the page
flow controller. If this is insufficient, we should discuss it. In
your example (synchronizing the entire request), it seems like we'd need
to be synchronizing *across* forwarded requests (to get both the action
and the page render in one block, for instance), which seems sketchy.
Am I understanding your question here?
Daryl Olander wrote:
I guess, I'm trying to understand what the contract the control container
(the page flow runtime) has with respect to controls used there. For
example, should we be synchronizing the entire request against the current
page flow so that the request/response and resource lifetimes are enforced
for the request? Right now this isn't how the page flow runtime works.
On 1/16/06, Rich Feit <[EMAIL PROTECTED]> wrote:
I'm actually not the best person to answer questions about the threading
model for controls themselves, but as to shared flows, you're right --
you can get two threads into a shared flow when accessing it directly
from a page flow. This should be mentioned somewhere in the docs, but
it isn't. Basically, I think it's theoretically possible to synchronize
on every referenced shared flow when entering a page flow (doing it in
some deterministic order to avoid deadlock issues when hitting multiple
page flows that reference the same set of shared flows), but the
performance impact always seemed high. What do you think?
Daryl Olander wrote:
Rich, if you could comment on this I'd appreciate it.
I'm trying to understand the contract we hold with controls. I believe
that
we say that controls are single threaded. The issue is what do we say
about
the scope of the resource events (onAcquire and onRelease). Within a
page
flow, the onAcquire is raised on the first call to a control method.
onRelease is then called at the end of the request processor and in the
filters. onAcquire can be called multiple times but is called on the
control only once until the onRelease event is called.
I believe that this results in a pretty fundamental design problem inside
of
shared flows. If there are multiple threads in the same session, running
against different page flows instances, they may share shared flows. As
far
as I understand it, this means
1) Shared flows can have two threads running inside them at a time (?)
2) That the onAquire/onRelease are tied to on request but shared between
two
requests. (The result is that you can share the database connection in a
database control against two requests)
Seems like you end up with something like this:
1) Thread 1 calls a method on a control defined in a shared flow which
calls
onAcquire() on the first thread (and associates the request/response in
the
bean context with Thread 1's request.
2) Thread 2 enters a second page flow and calls a control on the same
shared
flow instance. onAcquire isn't called and the request from thread 1 is
still active in the controls bean context
3) Thread 1 exists the action and calls onRelease() on the shared flow
4) Thread 2 calls another method on the control. Now onAcquire() is
called
and the request from Thread 2 is used in the bean context
5) Thread 2 exists the action and calls onRelase() on the shared flow
Rich can you confirm this understanding?
Thanks
