Firebird, IBDAC, WLAN (wackliges Kabel ...), Verbindungsabbrüche

[hoika]

Hallo #,

ein Kunde hat mehrere Rechner im Netz,
einer über im WLAN.
Beim Start unserer Anwendung wird eine Connection aufgebaut,
die bleibt immer offen.
Dummwerweise ist sein WLAN-Kabel etwas brüchig ( ),
ab und zu ist das Netz weg und schon knallt die Anwendung.

FIBPlus hatte eine Art Caching-Mechanismus (wurde auch gross beworben),
damit wurde die Verbindung nach einem Abbruch incl. aller Queries
automatich wieder aufgebaut.
Bei IBDAC finde ich nichts.

Kennt jemand da eine andere Lösung.

DummyPacketInterval aus der Conf kann ich nicht benutzen,
weil der Server Windows hat.

Danke


Heiko

[MarcoWarm]

Hallo hoika,

wir haben bei uns im Unternehmen die Erfahrung gemacht, daß es best practice ist nicht darauf zu vertrauen, daß eine Verbindung immer offen bleibt.
Die UIB und FIBPlus Datenbank Komponenten unterstützen dafür das OnConnectionLost Ereignis. Wir haben die Klassen also einfach erweitert, daß sie bei einem Verbindungsabbruch den Nutzer informieren und die Verbindung nach einer Wartezeit oder durch Nutzerinteraktion wieder aufbaut. Es ist natürlich ärgerlich wenn es grad in einer Transaktion abbricht, allerdings haben wir ja alle von ibexpert gelernt, daß Transaktionen nur so kurz wie möglich offen bleiben sollen.
Es sind nur ein paar Zeilen Code... aber sie können dir ne Menge Beschwerden ersparen.

Gruß
Marco

[hoika]

Hallo,

ja, aber ...
Es könnte ja eine Query aktuell offen sein?
Was dann ?



Heiko

[MarcoWarm]

Hallo hoika,

Zitat von hoika:

ja, aber ...
Es könnte ja eine Query aktuell offen sein?

wie lange hälst du deine Transaktionen offen? Die Daten kannst du ja auch in einem ClientDataSet halten. Du könntest dir auch eine Art Framework bauen, in dem du die Datenbankzugriffe abstrahierst. Zum Beispiel:

procedure QueryData(ASQL: String; AParams: Variant; AOutCDS: TClientDataSet); Der Vorteil hierbei ist, daß du von der DB Engine unabhängig wirst, und du nur noch an einer Stelle überhaupt DB Zugriffe hast. Wenn der Kunde dann eine andere DB will, kannst du ganz einfach umsteigen.

Gruß
Marco

[mkinzler]

IBDAC unterstützt zudem disconnected DataSets

[dataspider]

Zitat von hoika:

Hallo #,
Bei IBDAC finde ich nichts.

Da gibt es das Property LocalFailOver in Verbindung mit OnConnectionLost.

Hier z.B. ein Foreneintrag.

Kann man das nicht verwenden?

Frank

[hoika]

Hallo,

das mit dem LocalFailOver ist schön,
aber dazu müsste ich einen Haufen Code umbauen ;(


Heiko

[Sir Rufo]

Zitat von hoika:

Hallo,

das mit dem LocalFailOver ist schön,
aber dazu müsste ich einen Haufen Code umbauen ;(


Heiko

Bist du dir da sicher?

Man kann als Reaktion auf ein ConnectionLost eine ReconnectExecute geben, was die Verbindung veranlasst die Verbindung wieder aufzubauen und das fehlgeschlagene Statement zu wiederholen.

Irgendwann sollte man das aber doch als Fehler behandeln, denn wenn der Server mal heruntergefahren werden muss, dann hast du auf allen Clients eine Endlosschleife

Ein blödes hat es allerdings, wenn du Locks benutzt, denn die hängen an der Session, und die Session ist bei einem Verbindungsabbruch halt abgelaufen und damit sind auch die Locks für selbige erledigt.

Darum baue ich dafür eine eigene Lock-Tabelle auf, die auch solche Verbindungsabbrüche unbeeindruckt läßt

[hoika]

Hallo,

Zitat:

was die Verbindung veranlasst die Verbindung wieder aufzubauen und das fehlgeschlagene Statement zu wiederholen.

hm, habe ich aber z.B. 2 Queries offen,
eine hält Daten offen, die andere aktualisiert auf Basis dieser Daten
über eine andere Query eine andere Tabelle (als Bsp.).

ist halt "gewachsener Code".

Hätte ich tatsächlich zum Zeitpunkt des Verbindungsabbruchs nur eine Query offen,
würde das ja gehen, es sei denn ich merke mir alle Queries:
SQL-Statement, Parameter (?), Position (Cursor !!!). ;(


Heiko