MySql Serververbindung nach Ruhemodus

[strzata]

Hallo,
die neuen Surface Pro unter WIN 8.1 sind schon ein Knaller. Leider hat mein Progrämmle damit Schwierigkeiten, denn Herunterfahren und neu Starten ist nun nicht mehr In. Die meisten Anwender schicken den Rechner nur in den Ruhemodus. Beim Aufwecken ist er blitzschnell wieder oben und man kann mit allen geöffneten Programmen sofort weiter arbeiten. Nur mit meinem nicht

Schuld ist die MySql Serververbindung. Alle Datenbankabfragen (ein paar Dutzend Funktionen) habe ich in einer Klasse gekapselt. Vor jedem Kommando frage ich ab, ob die Connection geöffnet ist (If _conn.State = ConnectionState.Open) und öffne sie, wenn nicht (_conn.Open). Nach dem Erwachen aus dem Ruhemodus knallt es, wenn mein Programm noch offen ist. Das liegt daran, dass mir eine offene Connection vorgegaukelt wird (Status ist Open und ein _conn.Open wirft eine Exception). Sie ist aber nicht offen (auch nicht "broken"), denn sobald ein Command ausgeführt werden soll (z.B. da.Fill(dt)), fliegt es mir um die Ohren. Ich müßte erst ein _conn.Close machen und danach wieder ein _conn.Open. Dann funktioniert es.

Ich wollte das PowerModeChanged-Ereignis nutzen, um dadurch alle Verbindungen zwangsweise zu trennen, wenn der Rechner geweckt wird. Aber das funktioniert nicht auf allen Rechnern. In jede der vielen Funktionen einen Try-Catch-Block einzubauen würde funktionieren, erscheint mir aber nicht sinnvoll und zu aufwändig. Hat jemand eine Idee, wie ich das lösen könnte?
Danke und viele Grüße
Norbert

[Ralf Jansen]

Das übliche ist die Connection nicht dauerhaft offen zuhalten.

Also öffnen, Daten holen, sofort schließen, Daten bearbeiten, connection öffnen, In db speichern, sofort wieder schließen etc. Hinter dem ganzen werden die Connections eh gepoolt. Schließen, öffnen kostest also kaum was und der Pool sollte eigentlich sauber auf diesen Fall vorbereitet sein so das du aus dem Pool keine kaputten Connections bekommst. Das sofort closen, zerstören etc. Ist das übliche für alle Datenbank Komponenten die ein Dispose veröffentlichen und somit den using Syntax (oder das VB Equivalent, ich weiß nicht wie es da heißt) unterstützen.

[strzata]

Also, das habe ich wirklich nicht gewußt. Mehrere Datenbankprogrammierer haben mir immer gesagt, man sollte die Connection offen halten, wenn ständige Anfragen (manchmal mehrere pro Sekunde !) kommen. Ist diese Meinung obsolet?

Meinst Du mit der using-Syntax das "Imports" in VB oder das using für einen Codeblock? Und kostet das ständige Auf- und Zumachen wirklich nix?
Danke für Deine Hilfsbereitschaft.
N.

[Ralf Jansen]

Mehrere Datenbankprogrammierer haben mir immer gesagt, man sollte die Connection offen halten

Vermutlich Generation 40+ die ihr Handwerk in Ihren Jungenjahren direkt an der Datenbank API gelernt haben. Das Pooling hält ja im Prinzip die Verbindung auch auf nur offen macht es aben eben nicht so billig einfach eine globale Variable zu verwalten. Sondern potientiell mehrere in einer threadsicheren Weise und berücksichtigt (wenn gut implementiert) auch so Sachen wie irgendwelche Stromsparmodi/Hybernate etc.

Meinst Du mit der using-Syntax das "Imports" in VB oder das using für einen Codeblock?

Ich meine den Codeblock also das Ding das das Ausführen von Dispose erzwingt.

Und kostet das ständige Auf- und Zumachen wirklich nix?

Das müßtest du in der von dir verwendeten MySql Komponente nachschlagen ob die Pooling implementiert haben. MySql ist ja nicht gerade .Net Standard und ein passender Client wäre im Framework. Aber eigentlich machen das alle die ich kenne.
Der Standard Connector den man by mysql runterladen kann macht es laut Doku auch.

[strzata]

Hab bis jetzt in Deinem Link und anderen Quellen rumgelesen und weiss nun, dass ich nichts weiss. Muss nochmal was fragen: warum reicht nicht ein einfaches Close? Warum muss noch das Dispose da sein? Es ist kein Problem, in meinen Funktionen überall das using einzufügen. Möchte es halt nur verstehen.
Im übrigen: ich benutze MySql 6.5 und den dazugehörenden MySql.Data.MySqlClient. Da scheint Pooling ja kein Problem zu sein.

[Christian Marquardt]

ich benutze MySql 6.5

Wie machst du das, wo doch 5.7 erst raus ist?

[Ralf Jansen]

Muss nochmal was fragen: warum reicht nicht ein einfaches Close

Close und Dispose läuft hier auf das gleiche hinaus, Dispose wird Close aufrufen, du kannst also auch Close nehmen. Aber using ist halt die absolut sichere Variante man kann das Close/Dispose nicht falsch machen oder vergessen. Wenn du das mit dem Close von Hand machst kannst du mir garantieren das das immer aufgerufen wird? Das du es nie vergisst? Das du immer auch sauber try...finally Blöcke benutzt so das auch im Fehlerfall immer Close/Dispose aufgerufen wird? Wenn ja dann benutze von mir aus Close.

Wie machst du das, wo doch 5.7 erst raus ist?

Die von mir verlinkte Doku ist Kapitel 6. Bei den ganzen Zahlen kann man schon mal durcheinander kommen oder der MySql Connector ist gemeint.

[strzata]

Danke! Ja, Zahlendreher: 5.6

[ericbk]

A. Kühnel geht auf dieses Thema ein (2010 oder 2012) im Thema Destruktor. Etwa so:
Weil bei jedem Öffnen einer Connection auch auf der Serverseite Objecte 'entstehen', reicht es nicht auf der Clientseite nur zu schliessen, der Server weiss davon nichts und hält weiter diese Objecte vor. Erst mit der Zerstörung des Connectionobject verschwienden auch diese.

Sollte es dann nicht besser sein, innerhalb einer Routine oder eines Prozesses, eben nicht dauernd zu schliessen und zu öffnen, sondern offen halten bis der Prozess durch ist. Erst recht wenn es was zu speichern gibt, in verschiedene Tabellen, und das ganze in eine Transaktion eingebunden ist?

[strzata]

@ericbk:
Du kannst Dich eigentlich darauf verlassen, dass die Antworten hier im Forum auf dem aktuellsten Stand sind. Das ist jedenfalls meine Erfahrung, denn ich habe hier schon Problemlösungen bekommen, die sonst nirgendwo zu finden waren.

Ich kann nur aus meinen eigenen praktischen Erfahrungen berichten. Wir haben eine riesige Datenbank mit über 100 großen Tabellen und mehreren Millionen Datensätzen auf einem Linux-Server laufen. Meist arbeiten fünf Clients gleichzeitig darauf und holen und schreiben Daten. Mitunter werden innerhalb einer Sekunde bis zu acht Commands abgeschossen. Jahrelang waren wir ganz zufrieden. Als nun ein Tablet-PC ins Spiel kam und zusätzlich einige Smartphones über VPN an den Server angebunden wurden, traten die ersten Probleme auf. Es kam immer wieder zu Abstürzen. Das Problem habe ich oben schon beschrieben. Ich habe die Software umgeschrieben und mach jetzt immer die Verbindungen mit Dispose zu. Seitdem läuft wieder alles wie geschmiert.

Um herauszufinden, was dieses dauernde Öffnen und Schliessen der Connections eigentlich mehr kostet, haben wir ein Testprogramm geschrieben und die Zeiten gestoppt. Der Unterschied ist echt zu vernachlässigen. Zum Beispiel dauern 50 Commands (Lesen / Schreiben) mit offen gelassener Verbindung 48,2 Sekunden. Die gleichen Abfragen mit ständigem Schliessen und neu Öffnen dauern 48,9 Sekunden. Für uns fiel da die Entscheidung ganz leicht.

Grüße Norbert

[Ralf Jansen]

Sollte es dann nicht besser sein, innerhalb einer Routine oder eines Prozesses, eben nicht dauernd zu schliessen und zu öffnen, sondern offen halten bis der Prozess durch ist. Erst recht wenn es was zu speichern gibt, in verschiedene Tabellen, und das ganze in eine Transaktion eingebunden ist?

Das schließen einer DBConnection führt nicht zu einem Abbruch der Verbindung zum Server. Close/Dispose bedeutet zurücklegen der Verbindung in den Pool. Es ist ein rein logisches schließen der Verbindung. Zumindest solange man den Connection Pool nicht ausschaltet. Der Connection Pool ist intelligent genug die Resourcen irgendwann freizugeben falls die nicht mehr abgerufen werden und kann eben auch mit so Dingen wie dem Ruhe Modus umzugehen. Wenn du meinst es ist besser die Connection offen zu halten versuche mal die ganzen Probleme (Netzwerkwackler/Unterbrechungen/Hibernation etc.) die daran hängen tatsächlich zu lösen. Letztlich wirst du bei etwas landen das Äquivalent zum schon vorhandenen Connection Pool ist. Das kann man tun wenn man glaubt es besser zu können oder man ignoriert die ganzen Probleme

Natürlich sollte man die Connection nicht schließen bevor eine Transaktion zu Ende ist. Die Transaktion hängt an einer Connection das wäre also eh nicht möglich. Die Faustregel lautet die Connection so früh wie möglich zu schließen aber eben nicht früher.
Man ist in solchen Fällen gut unterwegs wenn Transaktion und Connection in etwa die gleiche Lebenszeit haben.


Edit:

Meintest du mit deinem Hinweis das hier? Dann hat der Author einfach einen didaktischen Fehler gemacht und erst im Folgekapitel "23.2.5 Verbindungspooling" beschrieben wie es standardmäßig ist. Wenn man solche Sätze liest "Eben wurde noch gesagt, dass mit dem Aufruf der Methode Close die Verbindung zu der Datenbank geschlossen wird. Wollen wir präzise sein, stimmt diese Aussage nicht " kann man nur die Augen verdrehen. Dem Author muss doch klar sein wenn man einen Leser Seitenweise quält, dieser glaubt es verstanden zu haben und im dann einen Spruch ala "Ätsch war gelogen" drückt er wenig Motivation hat weiterzulesen