You are very right , after thinking about it. After login, my web app wouldn't be able to keep the connection object around, unless I knew the apache implementation was single threaded, or multithreaded with a non-threaded object area , so I need to save the dsn, and recreate the connections for each query on the backend ! Maybe need to wrap the business stuff as a real server process then, and maybe do pre-initialized multiple business servers, that store login identities as tokens, just like apache multi-process ! What a headache!
On Mon, 2007-02-05 at 09:20 +0100, Karsten Hilbert wrote: > On Mon, Feb 05, 2007 at 08:57:52AM +0800, Syan Tan wrote: > > > if a get_connection call succeeds with a dsn, > > is that added to the pool, and then business objects > > will find it, or does a handle to the conn object have > > to be passed somewhere ? > > The get_connection() returns a connection authenticated for > the DSN passed in or for the DSN set as the default. > > Eventually, I want to add pooling the connections so that > when get_connection() is called with pooled=True it will > return a connection from the pool - if one is available for > the DSN. I have not gotten around to figuring out all the > details (thread safety etc). The external interface won't > change, however: > > conn = gmPG2.get_connection(...) > curs = conn.cursor() > > So, yes, you will have to pass in the connection to the > business objects. > > However, since that would be very cumbersome, you can also > set a default DSN to use for connections and call methods > which require a <link_obj> parameter (such as > gmPG2.run_ro/rw_queries()) with a value of None. They will > then get their own connection from gmPG2 with the previously > set default DSN. This will start a lot of connections and > for that pooling should help tremendously. If you can help > me to figure out how to safely enable pooling I'd be > delighted to add it in. > > BTW, thos <link_obj> parameters can take None, a connection, > or a cursor, for convenience. > > Karsten _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
