Zugriffe aus Threads heraus

[Markus Gronotte]

Halo zusammen,

Ich hätte gerne mal gewusst wie ihr das prinzipiell macht,
wenn ihr Zugriffe aus mehreren parallel laufenden Threads heraus programmiert.

Baut ihr dann in jedem einzelnen Thread eine eigene Verbindung auf,
oder baut ihr die Verbindung im Hauptprogramm des Clients nur einmal
auf und reicht diese Verbindung dann irgendwie an alle Threads weiter?

Gruß,
Markus

[Markus Gronotte]

Hallo zusammen,

Ich hätte gerne mal gewusst wie ihr das prinzipiell macht,
wenn ihr Zugriffe aus mehreren parallel laufenden Threads heraus programmiert.

Baut ihr dann in jedem einzelnen Thread eine eigene Verbindung auf,
oder baut ihr die Verbindung im Hauptprogramm des Clients nur einmal
auf und reicht diese Verbindung dann irgendwie an alle Threads weiter?

Gruß,
Markus

[Peter]

Post by Markus Gronotte
Hallo zusammen,
Ich hätte gerne mal gewusst wie ihr das prinzipiell macht,
wenn ihr Zugriffe aus mehreren parallel laufenden Threads heraus programmiert.
Baut ihr dann in jedem einzelnen Thread eine eigene Verbindung auf,
oder baut ihr die Verbindung im Hauptprogramm des Clients nur einmal
auf und reicht diese Verbindung dann irgendwie an alle Threads weiter?

Für die meisten Datenbanken ist eine Session auf der Client-Seite an
den Thread gebunden, der sie anlegt (d.h. in dem die Anmeldung an die
Datenbank erfolgt). Die Session dann aus einem anderen Thread heraus zu
verwenden ist entweder nicht möglich oder führt zu einer Serialisierung
innerhalb der Client-Library.

Maßgeblich ist hier nicht der Datenbank-Server (die sind immer
multithreaded oder verwenden für jede Session einen eigenen Prozess)
sondern die auf der Clientseite verwendete Library zum Zugriff auf den
Datenbankserver. ADO z. B. bindet eine Connection an eine Thread, aber
man kann COM interthread marshalling nutzen, um die Connection auch aus
einem anderen Thread zu verwenden (jedenfalls sieht es dann so aus, im
Wirklichkeit gibt COM Aufrufe intern an den Thread weiter, der die
Connection angelegt hat).

De facto machen es diese Limitierungen ziemlich schwierig, mit den
Delphi-Datenbankkomponenten über Threadgrenzen hinweg zu arbeiten. Wenn
Thread A die Datenbankabfrage an Thread B delegieren will muß letzerer
den kompletten Resultset vom Server holen, in einer geeigneten Weise
speichern (z. B. in einer Liste von Objekten oder einem
TClientDataset), und diesen Speicher an Thread A übergeben. Eine offene
Query zurückzugeben läuft gegen die Wand, wenn Thread A durch den
Resultset scrollt und dabei Daten vom Server nachgeladen werden
müssen...

[Markus Gronotte]

"Peter"

Hallo Peter

Post by Peter
De facto machen es diese Limitierungen ziemlich schwierig, mit den
Delphi-Datenbankkomponenten über Threadgrenzen hinweg zu arbeiten. Wenn
Thread A die Datenbankabfrage an Thread B delegieren will muß letzerer
den kompletten Resultset vom Server holen, in einer geeigneten Weise
speichern (z. B. in einer Liste von Objekten oder einem
TClientDataset), und diesen Speicher an Thread A übergeben. Eine offene
Query zurückzugeben läuft gegen die Wand, wenn Thread A durch den
Resultset scrollt und dabei Daten vom Server nachgeladen werden
müssen...

Danke für die ausführliche Antwort.
Dann macht es dem MySQL-Server also nichts aus wenn
in hohen Belastungsfällen mehrere tausend Verbindungen pro Minute
auf und abgebaut werden. Das wollte ich nur wissen. Danke dir!


Gruß,
Markus

[Axel Schwenke]

Post by Markus Gronotte
Ich hätte gerne mal gewusst wie ihr das prinzipiell macht,
wenn ihr Zugriffe aus mehreren parallel laufenden Threads heraus programmiert.
Baut ihr dann in jedem einzelnen Thread eine eigene Verbindung auf,
oder baut ihr die Verbindung im Hauptprogramm des Clients nur einmal
auf und reicht diese Verbindung dann irgendwie an alle Threads weiter?

Einfach: letzteres funktioniert nicht. Also zumindest nicht
uneingeschränkt. Siehe dazu:

http://dev.mysql.com/doc/refman/5.1/en/threaded-clients.html


Wenn du eine massiv parallele Applikation hast, dann gilt es als
sauberste Lösung, eine(n Pool von) Service-Thread(s) vorzusehen,
an den ein "normaler" Applikations-Thread seine Queries delegiert.

Da das aber recht aufwendig werden kann, programmieren die meisten
Leute lieber so, daß sie jeden Thread der was von der Datenbank will,
seine eigene Verbindung aufmachen lassen. So lange die Anzahl
derartiger Threads nicht deutlich zweistellig wird, ist IMHO auch
nichts dagegen einzuwenden.

Der MySQL-Server implementiert das intern übrigens genau so. Jede
Verbindung startet einen Worker-Thread, der dann die Queries
abarbeitet, die über diese Verbindung reinkommen.


[skip zu anderem Posting von dir]

Post by Markus Gronotte
Dann macht es dem MySQL-Server also nichts aus wenn
in hohen Belastungsfällen mehrere tausend Verbindungen pro Minute
auf und abgebaut werden. Das wollte ich nur wissen.

Warum fragst du das dann nicht? Aber ja, MySQL kommt recht gut mit
mehreren hundert Connects pro Sekunde zurecht.

Aber nach allem, was ich bis jetzt so gehört habe, wäre evtl. der
embedded MySQL server aka libmysqld eher geeignet:

http://dev.mysql.com/doc/refman/5.1/en/libmysqld.html

Bei dieser Variante wird der MySQL-Server mit deinem Programm
zusammengelinkt und läuft als separate(r) Thread(s).


XL

[Thomas Rachel]

Post by Markus Gronotte
Halo zusammen,
Ich hätte gerne mal gewusst wie ihr das prinzipiell macht,
wenn ihr Zugriffe aus mehreren parallel laufenden Threads heraus programmiert.

Je nachdem, wie das Verhältnis von DB-Zugriffen su sonstigem Zeugs ist,
was so ein Thread zu erledigen hat, kann es auch funktionieren, die
DB-Verbindung mit einem Lock zu versehen, der gehalten werden muß, wenn
ein Thread auf die DB zugreift.

Keine Ahnung, ob und wie das unter Delphi geht - in Python klappts.

Gruß,
Thomas

Fup2 mysql - wo es aber auch nicht so richtig hinpaßt.