Une connexion à la DB par thread

Salut à toutes et à tous,

Dans le cadre d'un projet web, version WSGI, j'ai besoin d'avoir une connexion à la base de données. Il en faudra une par thread, bien évidemment.

En soi, rien de très compliqué: threading.local et on est en route.
Le souci, c'est que threading.local ne semble pas être notifié lorsqu'un thread se termine, et ne permet donc pas aux objets d'être recyclés par le gc.

Dans mons cas, ça signifierait que les connexions à la db resteraient ouverte pendant toute l'exécution du programme. Ce n'est bien entendu pas acceptable.

Petit exemple de code pour rendre les choses un peu plus concrètes:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

>>> import threading >>> >>> local = threading.local() >>> class MyClass: ... def __init__(self): print("Init'ing") ... def __del__(self): print("Deleting") ... >>> def test(): ... local.obj = MyClass() ... >>> threading.Thread(target=test).start() Init'ing

---

On peut voir qu'il n'y a pas de "Deleting", ni une seconde après, ni 3 jours après, puisqu'il reste une référence à l'objet dans le threadlocal.

Sachant que:
1. je n'ai pas la main sur la création des threads,
2. l'usage des weakref dans ce cas-ci n'est pas une possibilité,
comment puis-je m'assurer que les objets seront détruits une fois que le thread se termine ?

Je sais pas si j'apprend ca a un membre expert mais pour les thread, que je ne connait pas très bien, il existe une système de verrous (Semaphore) avec les méthodes acquire(), release(), locked() dans module thread il doit y avoir l'équivalent dans threading. Mais je crois que le problème est le code de retour.
Copy de la doc officiel Python 2.5.6

Citation:

---

current_thread()
currentThread()
Return the current Thread object, corresponding to the caller’s thread of control. If the caller’s thread of
control was not created through the threading module, a dummy thread object with limited functionality
is returned.

---

Je ne sais vraiment pas si ca peut t'aider...
et j'ai trouver ca dans la doc aussi:

Citation:

---

Semaphore Example
Semaphores are often used to guard resources with limited capacity, for example, a database server. In any
situation where the size of the resource size is fixed, you should use a bounded semaphore. Before spawning any
worker threads, your main thread would initialize the semaphore:
maxconnections = 5
...
pool_sema = BoundedSemaphore(value=maxconnections)
Once spawned, worker threads call the semaphore’s acquire and release methods when they need to connect to the
server:
pool_sema.acquire()
conn = connectdb()
... use connection ...
conn.close()
pool_sema.release()
The use of a bounded semaphore reduces the chance that a programming error which causes the semaphore to be
released more than it’s acquired will go undetected.

---

Escuse moi de t'avoir ennuyer et polluer ta question, je voulais juste t'aider.

Hello,

Les sémaphores sont justement quelque chose à laquelle je tente désespérément d'échapper dans ce cruel monde de l'informatique impérative :P

Cela dit, lire ton post m'a donné le déclic: le module "atexit".
Merci donc pour ton intervention :)

Ptit exemple de code pour les curieux:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

>>> import atexit >>> def test3(): ... local.b = MyClass() ... def do_exit(): ... del local.b ... atexit.register(do_exit) ... >>> threading.Thread(target=test3).start() Init'ing   Deleting

---

Bonsoir,

Voici ce que donne votre code pour moi

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

import threading from sys import version   if version.startswith('3'): raw_input = input   local = threading.local()   class MyClass: def __init__(self): print("Init'ing") def __del__(self): print("Deleting")   def test(): local.b = MyClass() print('local.b', local.b)   threading.Thread(target=test).start() raw_input() print('local.b', local.b)

---

Output

Code:

---

1 2 3 4 5 6 7 8

Init'ing local.b <__main__.MyClass object at 0xb745f48c> Deleting Traceback (most recent call last): File "testrd1.py", line 21, in <module> print('local.b', local.b) AttributeError: '_thread._local' object has no attribute 'b'

---

@+

Ola oui, il se passe des choses que je ne comprends pas bien il me semble...
Autant pour le coup de l'AttributeError c'est normal, puisque le thread n'est pas le même, mais voyez plutôt ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

>>> import threading >>> >>> def test(): ... local.a = MyClass() ... >>> local = threading.local() >>> class MyClass: ... def __init__(self): print("init") ... def __del__(self): print("del") ... >>> threading.Thread(target=test).start() init >>> threading.Thread(target=test).start() init   del >>> threading.Thread(target=test).start() init   del

---

Ah, mystère éclairci :)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

import threading   class MyClass: def __init__(self): print("Init #{0} in {1}".format(id(self), threading.currentThread().name))   def __del__(self): print("Del #{0} in {1}".format(id(self), threading.currentThread().name))     local = threading.local()   def witness(): local.a = MyClass()   threading.Thread(target=witness).start() threading.Thread(target=witness).start() threading.Thread(target=witness).start() threading.Thread(target=witness).start()

---

Ce qui nous donne (en tout cas sous Mac OS X Snow Leopard):

Code:

---

1 2 3 4 5 6 7 8 9

Init #4300297064 in Thread-1 Init #4300297424 in Thread-2 Init #4300297640 in Thread-3 Del #4300297064 in Thread-3 Init #4300298432 in Thread-4 Del #4300297424 in Thread-4 Del #4300297640 in Dummy-5   Exception AttributeError: "'NoneType' object has no attribute 'currentThread'" in <bound method MyClass.__del__ of <__main__.MyClass instance at 0x1005158c0>> ignored

---

Reste plus qu'à trouver un peu de doc pour déterminer sur quel événement le threadlocal lache les variables. À priori, je dirais qu'il vérifie ça à chaque accès, mais ça me parait un peu lourd...


Quelqu'un a des infos ?

Ah, et je viens de voir le "Dummy-5", kezako ?
EDIT: De la doc de python:

Citation:

---

threading.currentThread()¶
Return the current Thread object, corresponding to the caller’s thread of control. If the caller’s thread of control was not created through the threading module, a dummy thread object with limited functionality is returned.

---

Et allez, un ptit dernier pour la route :)

Je viens de jeter un œuil au code de threading.local. Curieux, lisez :)

Pour résumer, l'objet threadlocal contient un dictionnaire, qui est également lié au thread.

Quand on tente d'accéder, de définir ou de supprimer un attribut, le threadlocal se fait patcher pour avoir le dictionnaire du thread en cours.

Donc, à l'appel du premier witness(), deux objets références le dictionnaire qui contient les valeurs:
1. le thread
2. le threadlocal

Quand le thread se termine, il est détruit. Il ne reste donc plus qu'une seule référence au dictionnaire. Quand on accède aux attributs dans un autre thread, le threadlocal est patché pour avoir le dictionnaire du thread en cours.

L'autre dictionnaire est perdu à ce moment, d'où le gc tardif.