durusmail: quixote-users: Re: Request contexts
Request contexts
2003-12-11
Re: Request contexts
2003-12-11
2003-12-11
2003-12-12
2003-12-12
2003-12-13
2003-12-13
2003-12-16
2003-12-16
2003-12-16
2003-12-16
2003-12-15
Re: Request contexts
2003-12-16
2003-12-16
2003-12-24
2003-12-30
2003-12-31
Re: Request contexts
Dave Kuhlman
2003-12-16
On Sat, Dec 13, 2003 at 12:23:47AM +0000, Matt Goodall wrote:

[snip]

> 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.

OK.  I'm following this suggestion (Graham's I think).  What I've
done is to sub-class the Publisher class, and (1) in the
constructor of my sub-class I create a DB connection and (2) I
override the Publisher's start_request method so that it stuffs the
connection into the request object before each request is handled.
Is this an accepted Quixote-ism?

Here is some simple, sample code:

    class MyPublisher(Publisher):
        def __init__(self, root_namespace, config=None):
            Publisher.__init__(self, root_namespace, config)
            self.dbConnection = PgSQL.connect(CONNECT_ARGS)
        def __del__(self):
            self.dbConnection.close()
        def start_request(self, request):
            Publisher.start_request(self, request)
            request.dbConnection = self.dbConnection


(Again, trying for a little understanding here and remembering that
I'm using SCGI ...) This is safe (even if the database connection
itself is not thread-safe) because there is exactly one Publisher
instance in each process and there is only one request handler
active concurrently in a single process at any time.  In other
words, each process is single threaded, as Matt says above.)
Further more, each request is handled from beginning to end, before
another request is started in that process (though another request
may be concurrently handled in other process).  Have I got that
right?

And, my clean-up code works, too.  The __del__ method in MyPublisher
(my subclass of Publisher) is called whenever I restart or stop the
SCGI server.  Cool.

> >>
> >>
> >
> >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.

And, across processes a lock would do no good anyway, right?

> >
> >
> 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.

Right.  I was focusing on the solution before I really understood
the problem.  I could not get connection pools out of my head.  It
was more solution than I needed, I think.

Thanks.

Dave

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


reply