what I was thinking, was to use an xmlrpcserver wrapped wrapper to hold a token keyed dictionary of connections. Whenever a method is called on the server, e.g. find_patients( token, frag_names), get_patient(token, pat_id) would give a read-only serializable recursed dict object representing cPatient, and then have various update functions on the server e.g. update_item( token, pat_id, itempath, value); another client runs as a separate process, that periodically calls an expire() function on server, which makes it checks the connection dictionary, which is also stored with a last used time, and if the current time - last used time exceeds a certain value, then the connection would be closed and the token removed from the dictionary. tokens are stored on the mod_python side , on any type of session object, as they aren't active objects. a logout, will also call expire(token),
I suppose all this stuff is probably why people shortcut and try to fit in with a web framework. On Mon, 2007-02-05 at 14:21 +0100, Karsten Hilbert wrote: > On Tue, Feb 06, 2007 at 12:03:03AM +1100, syan tan wrote: > > > 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, > I didn't see things from this angle, but, yes. > > > so I need to save the dsn, and recreate the connections > > for each query on the backend ! > It depends. If you figure out a way to import gmPG2 *once* > per "http user session" you could rely on it to keep your > DSN around - as long as you do gmPG2.set_default_login() > somewhere along the way. If you then keep re-using that > imported-one gmPG2 you won't have to re-establish DSN. > However, one wouldn't want to re-use the DSN across several > HTTP-sessions (as in user-session, not as in > http-request-reply-session). > > It might be an idea to assign http-users a cookie and import > gmPG2 once per http-user storing the module instances in a > dict keyed on that user-cookie. > > Like a thin wrapper around gmPG2. > > Karsten _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
