Webware for Python

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

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

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

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

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

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

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