Connected=True während der ganzen Programmlaufzeit ?

[hoika]

Hallo #,

naja, der Text der Überschrift ist begrenzt

Wie macht ihr das mit dem Connected

1. Connected = True beim Programmstart
Connected = False beim Programmende

2. Connected = True vor jeder Transaktion
Connected = False danach


Ich benutze zur Zeit die 1. Variante.
Das Connect dauerte (damals IB6) je nach Server/Netzwerk ziemlich lange (0.5 sek).

Jetzt habe ich das Problem, dass bei "schlechtem" Netzwerk
mal die Verbindung abreisst -> böser SQL-Fehler wird angezeigt.

OK, man könnte vor jedem Transaktion-Start prüfen, ob die Verbindung noch da ist,
und zur Not die Verbindung wieder aufbauen.

Die 2. Variante finde ich aber besser.
Nur, wie sieht es mit dem Laufzeitverhalten aus ?

Ein Connection-Pool gibt es ja leider (für FB) nicht.

Nutzt jemand die 2. Variante und hat praktische Erfahrungen damit ?


Zum 1.
Wie kann ich schnell feststellen, ob die Verbindung noch besteht ?


Danke


Heiko

[Hansa]

Habe mal nachgesehen, im (Haupt)DataModuleCreate steht bei mir Database.Open und eine Transaktion wird gestartet. Lost Connection wegen Netzwerkkabel ziehen und so ? Guck mal dazu auf den FibPlus Seiten. Da müsste genaue Anleitung sein. Sie haben auch spezielle Ereignisse für Database und Dataset. OnLostConnect, DatabaseDisconnect usw. Siehe Artikel.

[alzaimar]

JDBC schickt z.B. vor jedem SQL-Knödel ein 'SELECT 1' zum Server.

[hoika]

Hallo

> Hansa
Meinst du den ?

http://www.devrace.com/en/fibplus/articles/4073.php

> alzaimar
Unter FB wäre das eine select 1 from rdb$database
exec: 3 ms, fetch: 11 ms

Ist eine schöne Belastung fürs Netzwerk ;(


Heiko

[alzaimar]

Zitat von hoika:

Ist eine schöne Belastung fürs Netzwerk ;(

Nein. Denn es werden 'SELECT 1'+'1' = 8 Bytes + Info = ca. 100 Bytes verschickt = 1 Frame. Eigentlich kein Problem. Aber uncool ist es schon. Der JDBC-Treiber für MSSQL wurde ja auch von Microsoft entwickelt. Wollte halt nur 'ne gängige Schwachsinnslösung vorschlagen.

Wenn es anders geht, dann wäre das natürlich besser.

Ich würde das Verschicken vielleicht zentral kapseln und über ein Try-Except erst die Verbindung ggf. neu aufbauen und danach einen neuen Versuch starten. Ich denke mir, das es auch bei FB zu Deadlock-Situationen kommen kann, bei denen man einen ansonsten unkritischen Befehl nochmals schicken muss. Ich mach das jedenfalls so (bei Deadlock max 3x, ein Reconnect max 1x).

Ich hab mir eh abgewöhnt, mit datensensitiven Steuerelementen zu arbeiten, bastle mir meine SQL selber zusammen und schicke sie über eine einzige Routine, die dann die ganze Deadlock, Reconnect etc. -Logik ausführt. So kann ich mir meine SQL-Batches zu

[Hansa]

Zitat von hoika:

> Hansa
Meinst du den ?

Das ist zumindest einer zum Thema.

Zitat von alzaimar:

..Ich hab mir eh abgewöhnt, mit datensensitiven Steuerelementen zu arbeiten, bastle mir meine SQL selber zusammen und schicke sie über eine einzige Routine, die dann die ganze Deadlock, Reconnect etc. -Logik ausführt. So kann ich mir meine SQL-Batches zu

Bring mal Beispiel.

[hoika]

Hallo,

die Transaction-Befehle habe ich auch gekapselt,
dort könnte ich das mit reinpacken.


Heiko

[alzaimar]

Zitat von Hansa:

Bring mal Beispiel.

So etwa.

Delphi-Quellcode:

Function ExecuteSQL (Const anSQLStmt : String) : TExecuteResult;
  Procedure _InnerExecute;
  Var
    iRetryCount : Integer;

  Begin
    Result := erNone;
    iRetryCount := 0;
    Repeat
      Try
        Connection.Execute (anSQLStmt);
        Result := erOK;
      Except
        On E:EDeadLockException Do Begin
          Result := E.SQLResult;
          inc (iRetrycount);
          Sleep (DELAY_ON_DEADLOCK);
        End;
        On E:ESQLException Do
          Result := E.SQLResult;
      End;
    Until (Result <> erNone) or (RetryCount = MAXRETRIES_ON_DEADLOCK); // z.B. 3
  End;

Begin
  Try
    _InnerExecute;
  Except
    On E:ELostConnectionException Do Begin
      Reconnect;
      _InnerExecute;
    End
  End
End;