[snip]
>
> > All things considered, I'd probably like (and use) this context
> > attribute you've introduced, as it provides a good place for storing
> > not just configuration info, but also things like my 'live'
> > application instance.

I've followed this thread and I'm trying to understand the proposal
here.

Is this context object a single object that is shared across all
requests in a Quixote application?  If so, can each request modify
and add to the context object (for example, if the context object
were a list or dictionary)?

It sounds like a great idea.

But, ...

Would that be safe?  My understanding is that, with SCGI at least,
different requests are running in separate processes.  Perhaps they
even have separate (Python) global interpreter locks.  So would
they be safe from each other when they modified the context object?

Am I not understanding the concept?

In an earlier message Graham said:

> For example, one could create a database connection as a context
> object, set it in the publisher, and thus make it available to
> all requests that need it.

But, wouldn't there need to be protection (some kind of lock) so
that only one request used the database connection at a time?  And,
of course, the next step would be to implement a connection pool
that could be shared, would allow check out and check in of
connections, etc.

I'm using the word "request" here to refer to the activation of my
Quixote application in response to an HTTP request.  Is "request"
the right term?  I think Graham talked about the passing the
context object into each request's namespace.

Dave

--
Dave Kuhlman
dkuhlman@rexx.com
http://www.rexx.com/~dkuhlman