I've been working a lot on the next version of OpenInteract. Many things
are changing -- all for the better, of course. One of the main goals is
to allow OI2 to run under different environments than Apache/mod_perl
1.x. In pursuing this goal I've run into a little sticking point that
maybe someone has some experience with. (I brought this up recently on
the P5EE mailing list if it sounds familiar...)
OI2 separates the monolithic OpenInteract::Request ($R) object into
three objects:
- Context (configuration, lookups, service access, other runtime state
and resources)
- Request (client info, cookies, session, GET/POST params)
- Response (outbound cookies, headers, content, template info).
The Context is a singleton, created once at server startup and never
destroyed. Each incoming request creates a Request and Response object
to deal with that request. The Request and Response are then disposed
once the request is finished.
Originally I'd intended the Request and Response to be associated with
the Context. But AFAIK this will break horribly in a threaded
environment, since the Context would be considered a member of all
threads.
The only ways I see around this are:
- Pass the request/response around everywhere. This seems to work for
Servlets ok. But there are pieces of the OI framework (like SPOPS
objects) that depend on getting information from the current request
(like the current user/groups) to do their jobs. Maybe this is too tight
a coupling and it needs to be rethought anyway.
- Whenever we encounter a threaded environment, just create a new
Context object per thread and continue to associate the current
Request/Response with a context. I haven't used threads before so I
don't know how easy/feasible this is. (As a variation, we might be able
to keep the Context global but create a per-thread variable that
contains just the Request/Response and is accessible from anywhere in
the thread.)
Thanks for your ideas,
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
