gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] observations on the web gui challenge


From: Richard Taylor
Subject: [Gnumed-devel] observations on the web gui challenge
Date: Thu, 14 Oct 2010 15:20:07 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

Hi

I have been trying to work up an example of the session based solution
to the web gui problem of maintaining a connection per user to the database.

It has taken me a little while to setup a dev system and an example
setup that will do the session management and json-rpc using wsgi.

I have now started to look at calling into gmPG2.py to authenticate to
the database and then to expose the same interfaces that are in
gmWebGuiServer.py.

I think that I now understand the root of the complication that you have
been having that has led you towards the complex proxy solution. I will
try to explain the issue as I see it and see if you agree with the analysis.

Looking at gmPG2.py I notice that there are a number of methods that set
global variables and act as singletons. Notably:

        get_default_login():
        def get_default_dsn():
        def set_default_login(login=None):

>From what I can gather these are set after the initial connection to the
database and are then accessed from elsewhere in the code when ever a
database connection is required.

Because these are global it follows that it is only possible to have 1
connected user (i.e. default dsn) per process.

This explains why your proxy approach works. The forking TCP server will
create a new process for each initial HTTP connection (i.e. the first
from a specific client). The proxy then works to keep the TCP connection
alive and feed all subsequent HTTP requests down it. So the globals
representing the users connection are correct within that process. The
approach would not work for a threading server or an async server.

The underlying problem is not your need to have a different connection
per browser session. It is that you have only 1 default dsn per process.

The real solution to your web client problem is to refactor the database
access within the application so that it does not rely on singletons to
hold a default dsn.

If you could solve this issue and make the database connection a
parameter that is passed down to the database functions it would then
make it possible to use a conventional session based database connection
model.

All the best

Richard



reply via email to

[Prev in Thread] Current Thread [Next in Thread]