Hab mir [wiki]DB Transaktionen[/wiki] noch mal angesehen und eine DB Transaktion implementiert...
Aber irgendwie ist mir das noch nicht ganz klar, wie es funktioniert...
Ich hätte eigentlich damit gerechnet, das .rollback() und .commit() am cursor hängen, aber sie kleben am connection objekt...
Wie soll das funktionieren, bei threading??? Also wenn mehrere Threads sich eine connection teilen. Was doch IMHO bei einer fastCGI Anwendung der Fall sein kann.
Ich dachte eigentlich man macht sich an der "kritischen" Programmstelle ein neues Cursor-Objekt, macht damit rum und anschließend ein rollback oder commit. Gleichzeitig mach ein anderer cursor in einem anderen Thread irgendwas mit der DB und nicht's kommt sich in die Quere...
Kann mich da jemand Aufklären?
DB Transaktionen 2...
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Hm... Da schau einer an, aus ID mit cur.lastrowid bei PostgreSQL:
Gibt es auch eine Art "Seqenz Name" bei MySQL? Oder hat das nichts mit meinem oben geschilderten Problem zu tun?tabellar hat geschrieben:...
nextval('sequenz_name')
currval('sequenz_name')
setval('sequenz_name', newval)
lastval()
Diese Sequenzfunktionen sind sitzungsbezogen und sind von nextval()
Aufrufen anderen Benutzer nicht beeinflusst.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Hm. Das ist im Grunde momentan in PyLucid der Fall. Zumindest wenn es als CGI läuft. Da wird für jeden Request eine neue Verbindung aufgebaut.
Nur ich frage mich, was es dann mit den sog. Connection-Pools auf sich hat?
Nur ich frage mich, was es dann mit den sog. Connection-Pools auf sich hat?
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Jens!jens hat geschrieben:Nur ich frage mich, was es dann mit den sog. Connection-Pools auf sich hat?
Ich verwende in meinem Programm SW3 einen dynamischen Connection-Pool. Das bedeutet NICHT, dass jede Funktion, die eine Connection anfordert, die selbe Connection zugewiesen bekommt, sondern dass jede Funktion, die eine Connection anfordert, eine neue oder nicht mehr von anderen Funktionen verwendete Connection zugewiesen bekommt.
Jede Funktion holt sich also eine eigenständige Connection und teilt diese nicht mit anderen Funktionen.
In Python habe ich so etwas noch nicht programmiert, aber so schwer ist das ja auch nicht. Du musst dich nur darum kümmern, dass jede Funktion die eine Connection benutzt, diese beim Beenden der Funktion wieder frei gibt.
lg
Gerold

http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.