beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Control usage in Shared Flows
Date Mon, 16 Jan 2006 18:06:56 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message