From: William D. <wi...@fl...> - 2008-10-06 14:07:46
|
Hi, With python >= 2.4 you use threading.local in PersistentDB, but with some server (mod_wsgi) threading.local is not kept between requests because of the C implementation. We can also imagine that somes wsgi server will clean threading.local. If we force to use the python implementation it works (and there is a python implementation in PersistentDB.py) We spoke about that on the mod_wsgi list : http://groups.google.com/group/modwsgi/browse_thread/thread/75463f392f3ff5d9 thx to have look at this -- William Dodé - http://flibuste.net Informaticien Indépendant |
From: Christoph Z. <ci...@on...> - 2008-10-06 20:06:06
|
William Dode schrieb: > With python >= 2.4 you use threading.local in PersistentDB, but with > some server (mod_wsgi) threading.local is not kept between requests > because of the C implementation. We can also imagine that somes wsgi > server will clean threading.local. > If we force to use the python implementation it works (and there is > a python implementation in PersistentDB.py) Thanks for making me aware of that. So if you change PersistentDB to do "from _threading_local import local" instead of "from threading import local" or if you raise an ImportError so that the implementation in PersistentDB is used, then it works? That means we should probably make this configurable or always use the Python implementation (but the C implementation is faster). Other ideas? By the way, a pre-release of DBUtils 1.0 is available at http://www.webwareforpython.org/downloads/DBUtils/DBUtils-1.0pre.tar.gz If there are other things to consider for DBUtils 1.0, let me know. -- Christoph |
From: Christoph Z. <ci...@on...> - 2008-10-06 20:46:06
|
Christoph Zwerschke schrieb: > If there are other things to consider for DBUtils 1.0, let me know. Same for Webware 1.0 final. It's long overdue, but I just never found the time to make. Let me know if there is anything that needs to be fixed for the final release. I've now planned it for this week or next. -- Christoph |
From: William D. <wi...@fl...> - 2008-10-07 10:06:10
|
On 06-10-2008, Christoph Zwerschke wrote: > William Dode schrieb: >> With python >= 2.4 you use threading.local in PersistentDB, but with >> some server (mod_wsgi) threading.local is not kept between requests >> because of the C implementation. We can also imagine that somes wsgi >> server will clean threading.local. >> If we force to use the python implementation it works (and there is >> a python implementation in PersistentDB.py) > > Thanks for making me aware of that. So if you change PersistentDB to do > "from _threading_local import local" instead of "from threading import > local" or if you raise an ImportError so that the implementation in > PersistentDB is used, then it works? Yes, theses two solutions works > > That means we should probably make this configurable or always use the > Python implementation (but the C implementation is faster). Other ideas? Maybe the python implementation by default and an option tu use the C implementation (did you bench it ?). Like that most of the people will have nothing to do. > > By the way, a pre-release of DBUtils 1.0 is available at > http://www.webwareforpython.org/downloads/DBUtils/DBUtils-1.0pre.tar.gz > > If there are other things to consider for DBUtils 1.0, let me know. I just see that you added a closeable attribute, fine. There is no close method for all the pool of PersistentDB ? Why the _close method of the connection to force it is not public ? bye -- William Dodé - http://flibuste.net Informaticien Indépendant |
From: Christoph Z. <ci...@on...> - 2008-10-12 21:18:45
|
William Dode schrieb: > Maybe the python implementation by default and an option tu use the > C implementation (did you bench it ?). Like that most of the people will > have nothing to do. If I measured correctly, then with the C implementation you can get the connection 10% faster. That's not a big deal, so I have now made the Python implementation the standard, but added a parameter so that you can use any other implementation as well. > I just see that you added a closeable attribute, fine. > > There is no close method for all the pool of PersistentDB ? Yes, because it's not really a pool like in PooledDB. The connections are owned by the threads and are closed automatically when the threads are closed. > Why the _close method of the connection to force it is not public ? Since you should use the normal close method that heeds the closeable parameter. You can download the new version at http://www.webwareforpython.org/downloads/DBUtils/DBUtils-1.0rc1.tar.gz -- Christoph |
From: William D. <wi...@fl...> - 2008-10-22 09:08:39
|
On 18-10-2008, Christoph Zwerschke wrote: > William Dode schrieb: >> Then i have to set closeable when i create it ? >> What i would like is to have closeable set to False, and decide *after* >> (for maintenance of the db) that i want a brut close. > > You can set closeable to True when creating the PersistentDB instance, > then all connections will be closeable. But you usually don't want that. > Instead, the idea is to silently ignore the close and next time a > connection in that thread is requested, reuse that same connection. > When you close your application and all threads are shut down, then the > connections will be closed automatically. Closing them earlier will not > help, since PersistentDB will try to reopen them anyway when a thread > requests a new connection. If the database is shut down, then your > threads get connection errors, and when it is up again, new connections > will be opened again. You're right, i will handle this at the application level. I mean, it's safer to stop the application if i need some maintenance on the database. -- William Dodé - http://flibuste.net Informaticien Indépendant |
From: William D. <wi...@fl...> - 2008-10-15 11:26:23
|
On 12-10-2008, Christoph Zwerschke wrote: > William Dode schrieb: >> Maybe the python implementation by default and an option tu use the >> C implementation (did you bench it ?). Like that most of the people will >> have nothing to do. > > If I measured correctly, then with the C implementation you can get the > connection 10% faster. That's not a big deal, so I have now made the > Python implementation the standard, but added a parameter so that you > can use any other implementation as well. Fine, i confirm that rc1 works with mod_wsgi. > >> I just see that you added a closeable attribute, fine. >> >> There is no close method for all the pool of PersistentDB ? > > Yes, because it's not really a pool like in PooledDB. The connections > are owned by the threads and are closed automatically when the threads > are closed. You mean that it'll be not safe to close a connexion of an other thread? > >> Why the _close method of the connection to force it is not public ? > > Since you should use the normal close method that heeds the closeable > parameter. Then i have to set closeable when i create it ? What i would like is to have closeable set to False, and decide *after* (for maintenance of the db) that i want a brut close. In fact i've not more the problem since i use mod_wsgi, i stop the application completly... I'm just curious. thks > > You can download the new version at > http://www.webwareforpython.org/downloads/DBUtils/DBUtils-1.0rc1.tar.gz > > -- Christoph > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- William Dodé - http://flibuste.net Informaticien Indépendant |
From: Christoph Z. <ci...@on...> - 2008-10-18 14:20:23
|
William Dode schrieb: > Then i have to set closeable when i create it ? > What i would like is to have closeable set to False, and decide *after* > (for maintenance of the db) that i want a brut close. You can set closeable to True when creating the PersistentDB instance, then all connections will be closeable. But you usually don't want that. Instead, the idea is to silently ignore the close and next time a connection in that thread is requested, reuse that same connection. When you close your application and all threads are shut down, then the connections will be closed automatically. Closing them earlier will not help, since PersistentDB will try to reopen them anyway when a thread requests a new connection. If the database is shut down, then your threads get connection errors, and when it is up again, new connections will be opened again. -- Christoph |