Muss die Verbindung zur DB immer geschlossen werden?

[davar]

Hallo Leute,

zwar wurde die Frage bereits hier gestellt, jedoch hätte ich gern - wenn möglich - eine detailliertere Antwort.

In meiner Software habe ich verschiedene datensensitive Komponenten eingesetzt (DBEdits, DBGrids usw.). Wenn ich nun die Verbindung beende, wird in diesen Komponenten nichts mehr angezeigt, deswegen lasse ich die Verbindung einfach offen. Nun würd ich gern wissen, inwiefern es denn dann Probleme geben kann, wenn die Software im Netzwerk mit 4-5 Clients benutzt wird.

MfG

davar

[Bernhard Geyer]

Bei MySQL - eigentlich fast keine da MySQL keine serverseitigen Curser hat und damit offene Querys für die DB keine Last darstellen da immer sofort alle Datensätze zum Client übertragen werden. Und 4-5 offene DB-Verbindungen da lacht selbst MySQL darüber.

[Niko]

Hi,

vor .net Zeiten war es in Delphi üblich die Verbindung zur Datenbank über die ganze Programmlaufzeit offen zu halten. Wenn du die Verbindung häufig wieder benötigst ist das Schließen sogar ungünstig, da der Verbindungsaufbau jedesmal Rechenzeit kostet (beim Client und beim Server). Eventuell betreiben die Zeos-Komponenten aber auch Connection-Pooling, was bedeuten würde, dass die Verbindung beim Schließen im Hintergrund noch eine Zeit lang geöffnet bleibt, um bei Bedarf wiederverwendet zu werden.

Probleme beim Zugriff mehrerer Clients, die ihre Verbindungen jeweils lange offen halten, darf es bei einem vernünftigen Datenbanksystem nicht geben, schon gar nicht mit nur 4-5 Clients. Datenbanksysteme wie MySQL sind ja darauf ausgelegt, gleichzeitige Verbindungen von mehreren hundert Clients handhaben zu können. Die Maximalzahl an gleichzeitigen Verbindungen sollte sich in der Dokumentation der Datenbank finden lassen und kann auch durchaus abhängig von der eingesetzten Lizenz sein. Wichtig ist nur darauf zu achten, dass die Clients keine Transaktionen über längere Zeit geöffnet halten, denn damit würden sie den Zugriff auf die betroffenen Sätze durch andere Clients einschränken.

[davar]

Zitat von Niko:

Wichtig ist nur darauf zu achten, dass die Clients keine Transaktionen über längere Zeit geöffnet halten, denn damit würden sie den Zugriff auf die betroffenen Sätze durch andere Clients einschränken.

Was genau kann ich denn hier drunter verstehen? Wie bleibt denn eine Transaktion geöffnet?

[mkinzler]

Zitat:

Was genau kann ich denn hier drunter verstehen? Wie bleibt denn eine Transaktion geöffnet?

In dem man sie nicht schließt.
Bei MySQL kommt es aber auf die Storage-Engine an ob Transkationen überhaupt unterstützt werden.
Transaktioene sorgen dafür das zusammenhängende Datenmanipulationen entweder komplett durchgefüht werden oder komplett zurückgesetzt werden können. Je nach Transaktions-Isolation sind die Änderungen, dann für andere Clients erst nach einem Commit sichtbar.

[davar]

Und wie mache ich es denn am besten, wenn ich das Formular mit den datensensitiven Komponenten schließe? Auf TQuery kann ich nicht zugreifen, weil die Komponenten die Verbindung beibehalten. Die Komponenten sollen nicht ganz entfernt werden, weil das Formular immer wieder geöffnet wird, und für jedes Formular möchte ich nicht ein eigenes Query einsetzen. Wie mach ich das denn am sinnvollsten?

[mkinzler]

Welcher Isolationslevel steht in dein ZTransaction-Kompoenente?

[davar]

Zitat von mkinzler:

Welcher Isolationslevel steht in dein ZTransaction-Kompoenente?

hmm.. da bin ich jetzt ein wenig überfordert. Ich hab sie zwar eingebunden, aber im Quellcode kein einziges Mal angesprochen. Ist das denn notwendig?

[mkinzler]

Vermutlich unterstützt deine Storage Engine sowieso kein Transaktionen. Die Standard-Isolationsstufe ist meines Wissens auch eh autocommit.

[davar]

Zitat von mkinzler:

Vermutlich unterstützt deine Storage Engine sowieso kein Transaktionen. Die Standard-Isolationsstufe ist meines Wissens auch eh autocommit.

hmm. Was heisst das jetzt konkret für mich?