Verbindung ständig offen halten?

[Bernt]

Hallo,

ich habe eine Windows-Anwendung die immer wieder auf einen SQL Server 2000 zugreift. Manchmal jede 5-6 Sekunden, manchmal sind zwischen den SQL-Befehlen 2 Minuten dazwischen. Jede nach dem was der Benutzer gerade macht.

Sollte ich nun die Verbindung einmal öffnen und solange geöffnet lassen bis die Form geschlossen wird, oder ständig die Verbindungen öffnen?

[Daywalker]

Sollte ich nun die Verbindung einmal öffnen und solange geöffnet lassen bis die Form geschlossen wird, oder ständig die Verbindungen öffnen?

Wieviele parallele Verbindungen erlaubt die Datenbank? Wieviele Programminstanzen laufen gleichzeitig? Und wie lange dauert (in Sekunden) der Verbindungsaufbau genau?

Und dann bewerte für dich, ob der Wert einer um (mutmaßlich) Millisekunden schnelleren Applikation höher ist, als der eventuelle Ausschluß von Usern, weil die Datenbank keine Connections mehr annimmt.

[_King Lully]

ich habe eine Windows-Anwendung die immer wieder auf einen SQL Server 2000 zugreift. Manchmal jede 5-6 Sekunden, manchmal sind zwischen den SQL-Befehlen 2 Minuten dazwischen. Jede nach dem was der Benutzer gerade macht.

Sollte ich nun die Verbindung einmal öffnen und solange geöffnet lassen bis die Form geschlossen wird, oder ständig die Verbindungen öffnen?

Es ist zwar etwas pauschal, aber das Schliessen der Verbindung ist eigentlich immer eine gute Idee. Unseres Erachtens müsste ein "extravagantes" Szenario gegeben sein, um anders zu planen.

(Es gibt bspw. nichts schlimmeres als DBAnwendungen, die bspw. etliche Verbindungen aufmachen, dann noch abstürzen und Verbindungen aufechterhalten, da bestimmte Prozesse noch laufen.)

[Reiner]

Es ist zwar etwas pauschal, aber das Schliessen der Verbindung ist eigentlich immer eine gute Idee. Unseres Erachtens müsste ein "extravagantes" Szenario gegeben sein, um anders zu planen.

sorry, aber nicht nur pauschal sondern Firlefanz.
Bei performanten Anwendungen hüte ich mich, die Verbindung dauernd zu öffnen und wieder zu schließen, _wenn_ es sich irgendwie vermeiden läßt.

(Es gibt bspw. nichts schlimmeres als DBAnwendungen, die bspw. etliche Verbindungen aufmachen, dann noch abstürzen und Verbindungen aufechterhalten, da bestimmte Prozesse noch laufen.)

Dann sorge dafür, daß Deine Anwendung nicht abstürzt.
Und wenn Sie (mal) abstürzt, kann man ja immer noch ein Timeout einstellen, nach dessen Ablauf die Verbindung automatisch geschlossen wird.

Gruß
Reiner

[_King Lully]

Es ist zwar etwas pauschal, aber das Schliessen der Verbindung ist eigentlich immer eine gute Idee. Unseres Erachtens müsste ein "extravagantes" Szenario gegeben sein, um anders zu planen.

sorry, aber nicht nur pauschal sondern Firlefanz.
Bei performanten Anwendungen hüte ich mich, die Verbindung dauernd zu öffnen und wieder zu schließen, _wenn_ es sich irgendwie vermeiden läßt.

Schön!

(Es gibt bspw. nichts schlimmeres als DBAnwendungen, die bspw. etliche Verbindungen aufmachen, dann noch abstürzen und Verbindungen aufechterhalten, da bestimmte Prozesse noch laufen.)

Dann sorge dafür, daß Deine Anwendung nicht abstürzt.
Und wenn Sie (mal) abstürzt, kann man ja immer noch ein Timeout einstellen, nach dessen Ablauf die Verbindung automatisch geschlossen wird.

Sehr schön.

Dennoch: Besser ist immer schön Verbindung zum Datenserver schliessen.

[Klaus Mock]

Hallo,

Es ist zwar etwas pauschal, aber das Schliessen der Verbindung ist eigentlich immer eine gute Idee. Unseres Erachtens müsste ein "extravagantes" Szenario gegeben sein, um anders zu planen.

Sicherlich, aber der Zeitpunkt sollte mit Bedacht gewählt sein. Es gibt durchaus Datenbanken, bei denen der Verbindungsaufbau viel 'kostet', also relativ lange dauert. Hier nach dem Schema 'Verbindung öffnen, Abfrage/Modifikation durchführen, Verbindung schliessen' vorzugehen, ist meines Erachtens nach nicht zielführend.

(Es gibt bspw. nichts schlimmeres als DBAnwendungen, die bspw. etliche Verbindungen aufmachen, dann noch abstürzen und Verbindungen aufechterhalten, da bestimmte Prozesse noch laufen.)

1.) Vernünftige Datenbanken erkennnen (vielleicht auch erst nach einer bestimmten Zeitspanne) nicht existente Verbidnungen und schliessen diese.

2.) Halbewegs venünftig programmierte Anwendungen beinhalten auch ein Absturzszenario, bei dem zumindest alle geöffneten Resourcen (also auch Datenbankverbindungen) geschlossen bzw. freigegeben werden. Das ist imho eine Grundanforderung an jede Anwendung. Vielleicht, aber auch nur vielleicht, kann man schnelle Hacks oder Minimal-Prototypen davon ausnehmen, aber diesen Anwendungen ist ja naturgemäß eine kurze Lebensdauer beschert bzw., quasi als Ausgleich, sowieso etwas mehr Freiheit gewährt.

Das von Dir angesprochene Verhalten ist ein Bug, nichts weiter und deshalb auch kein Grund für eine (in meinen Augen) schlechte Designentscheidung.

Grüße
  Klaus

[_King Lully]

Es ist zwar etwas pauschal, aber das Schliessen der Verbindung ist eigentlich immer eine gute Idee. Unseres Erachtens müsste ein "extravagantes" Szenario gegeben sein, um anders zu planen.

Sicherlich, aber der Zeitpunkt sollte mit Bedacht gewählt sein. Es gibt durchaus Datenbanken, bei denen der Verbindungsaufbau viel 'kostet', also relativ lange dauert. Hier nach dem Schema 'Verbindung öffnen, Abfrage/Modifikation durchführen, Verbindung schliessen' vorzugehen, ist meines Erachtens nach nicht zielführend.

Nun, das von uns ins Auge gefasste Standard-Szenario ist eine Niederlassung oder Zentrale mit typischerweise max. 100 Nutzern, transaktionaler Datenzugriff und max. einem Datenzugriff pro Sekunde.
Das ist eine Standardsituation und damit haben wir Erfahrung. Zudem kennen wir keine Datenbanksysteme "bei denen der Vebindungsaufbau viel kostet" (Frage: wieviel?).
Und in der o.g. Umgebung ist es nach unserer Erfahrung günstig eine Verbindung pro Nutzer zuzulassen und diese immer brav zu schliessen. Das ist eine vernünftige Vorgabe, die Gründe sind weiter unten aufgeführt.
Bei noch mehr Nutzern sollte noch klarer sein, dass die Verbindungen nicht gehalten werden sollten.
Man sollte auch wissen, dass - wenn man in keiner grossen Softwareschmiede wie SAP oder MS arbeitet - Applikations-Bugs selbstverständlich sind. Oft läuft bspw. noch COBOL-Code oder VB-Code ohne zentralem Fehlermanagement.

(Es gibt bspw. nichts schlimmeres als DBAnwendungen, die bspw. etliche Verbindungen aufmachen, dann noch abstürzen und Verbindungen aufechterhalten, da bestimmte Prozesse noch laufen.)

1.) Vernünftige Datenbanken erkennnen (vielleicht auch erst nach einer bestimmten Zeitspanne) nicht existente Verbidnungen und schliessen diese.

In der Zwischenzeit hat aber eine schlechtprogrammierte? ;) DB-Sperre (Stichwort:Transaktionen) die Nutzer veranlasst das "DB-Problem" weiterzumelden und Aufwände zu generieren.

2.) Halbewegs venünftig programmierte Anwendungen beinhalten auch ein Absturzszenario, bei dem zumindest alle geöffneten Resourcen (also auch Datenbankverbindungen) geschlossen bzw. freigegeben werden. Das ist imho eine Grundanforderung an jede Anwendung.

Ist aber in bestimmten Programmiersprachen kaum bzw. gar nicht realisierbar. In der Praxis läuft oft alter Code, zudem auch nicht besonders präziser Programmierer. Warum? Nun - wenn man sich nicht in den SAP-Gürtel pressen lassen möchte, hat man eben eigenentiwckelte SW oder stark angepasste SW.

Vielleicht, aber auch nur vielleicht, kann man schnelle Hacks oder Minimal-Prototypen davon ausnehmen, aber diesen Anwendungen ist ja naturgemäß eine kurze Lebensdauer beschert bzw., quasi als Ausgleich, sowieso etwas mehr Freiheit gewährt.

Wir wissen nicht wo Du consulting machst, aber Du arbeitest mit Idealbildern.

Das von Dir angesprochene Verhalten ist ein Bug, nichts weiter und deshalb auch kein Grund für eine (in meinen Augen) schlechte Designentscheidung.

Ähh, "schlechte Designentscheidung" ist ja in ihrer Pauschalität "völlig" unrichtig.   ;)