Dave Kuhlman wrote:

>[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?
>
>
It depends on how you define safe ;-). With SCGI there is only one
request being handled by a single process at any time. Access to the
context and objects in it is inherently thread-safe (there's only one
thread) but trying to use the context to store information that must be
consistent across all of the application's SCGI processes will cause you
much pain. This is true of any process forking setup.

>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.
>
>
Assuming we're still talking SCGI here ...

Database connection use only needs to be synchronised in multithreaded
applications and, even then, some of the DB-API drivers are already
thread safe (when used correctly). Also, there is no point in using
connection pools with SCGI as each process only ever needs one
connection at most.

Cheers, Matt

--
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: matt@pollenation.net