IB6 und Router

[Gesine Kuhlmann]

Hallo,

Wir haben eine Anwendung, die über IBDataSet aud einen IB6-Server zugreift. funktioniert auch alles wunderbar. Nun wird auf den Server jedoch auch über einen Router zugegriffen, sodaß die physikalische Verbindung unterbrochen wird, wenn nach einer bestimmten Zeit keine Daten mehr übertragen werden. Fordert der Nutzer nun wieder Daten an, so baut der Router auch wieder eine Verbindung auf und alles funtkioniert. Nunu zu den Dingen, die nicht so gut funktionieren:

1)
Nach einer längeren Unterbrechungszeit, kommt keine Server-Verbindung mehr zustande. Das Programm 'rührt' längere Zeit und bricht dann ab.

2)
Auf dem Server bleiben 'Geister'-User ( alles Nutzer über Router ) übrig. Diese rühren vermutlich von nicht korrekt abgemeldeten Nutzern. Dazu die Frage: Werden die irgendwann von IB automatisch gelöscht wenn ja wann ? Wenn nein, wie kann man diese anders entfernen ?

3)
Manchmal kann gar keine Verbindung aufgebaut werden ( Gegenstelle besetzt oder gesperrt ). Wie beeinflusse ich das Timeout-Verhalten der Komponenten ?

[Andreas Kosch]

Hallo,

leider ist dieses Problem die Regel und nicht die Ausnahme. Wenn man die einschlägigen Newsgroups durchsucht, sind Unmengen von <i>".. connection lost to database..</i>-Hilferufen zu finden. Wenn man alle diese Meldungen durchsieht, scheint es eine Abhängigkeit zu bestimmten Router-Typen zu geben (allerdings hat dies nur Einfluss auf die Häufigkeit, aber nicht auf das Problem an sich). Die R&D-Leute von InterBase haben in eMails immer darauf hingewiesen, dass derartige "Zwangstrennungen" (die vom InterBase nicht erkannt werden können) problematisch sind.

Eine stabile Umgebung ist aus meiner Sicht nur unter den beiden folgenden Alternativen wahrscheinlich: <br>
1. Client trennt die Verbindung nach jedem Zugriff :-( <br>
2. Client greift über eine Three-tier-Anwendung nur indirekt auf die InterBase-Datenbank zu

[Resi]

Ist dieses Problem nur bezüglich IB6 die Regel oder kann auch unter IB 5.6 vorkommen

[Andreas Kosch]

Hallo,

das Problem taucht bei allen SuperServer-Versionen des InterBase (5.x; 6.x) auf. Nur der klassische Server (4.x) scheint davon nicht betroffen zu sein. In einer eMail der ehemaligen R&D-Truppe bei InterBase wurde darauf hingewiesen, dass grundlegende Änderungen notwendig sind, die frühestens erst ab der 7er-Version zur Verfügung stehen. Allerdings gibt es diese Truppe ja nicht mehr, so dass offen ist, ob sich das Verhalten jemals ändern wird

[Gesine Kuhlmann]

Hallo,

und was passiert nun mit einer Transaktion, die auf dem Server gestartet wurde und vom Client weder zurückgenommen noch bestätigt wurde ??

Was ist denn von den Replikationsfähigkeiten von IB6 zu halten ?

[Andreas Kosch]

Hallo,

wenn eine Transaktion zum Zeitpunkt der Zwangstrennung durch den Router offen war, muss man leider damit rechnen, dass beim nächsten Connect im Fehlerfall (.. connection lost to database..) diese Transaktion unerreichbar ist und somit ständig offen bleibt (bis der InterBase-Server heruntergefahren wird). Ein einer eMail hat ein R&D-Mann von InterBase die Umstände beschrieben, die zu diesem Problem führen können. Wenn ich mich richtig erinnere, war die Sockets-Anbindung dafür verantwortlich, dass der InterBase eine "neue" Verbindung (d.h. die Wiederherstellung durch den Router) nicht mehr zum "alten" Client zuordnen kann. Allerdings scheint dieser Effekt nicht sicher reproduzierbar zu sein, so dass er auftreten kann, aber nicht auftreten muss.

Bei der Replikation von Datenbanken gehe ich davon aus, dass hier die Verbindung ständig unter Last steht, so dass der Router keine Zwangstrennung initiiert.

Nun könnte man mit zusätzlichen Hilfsprogrammen dafür sorgen, dass die TCP/IP-Verbindung zwischen den beiden Rechnern ständig offen bleibt, indem diese Hilfsprogramm in regelmässigen Abständen Dummy-Daten übertragen. In diesem Fall legt der Router niemals auf, so dass es erst gar nicht zu einem Problem wird

[Gesine Kuhlmann]

Hallo,

1)
Das es bei der Replikation wegen fehlender Timeouts zu beträchtlich geringeren Verbindungsproblemen kommt, war der Ansatz für meine Idee, statt mit Online-Verbindungen mit lokalen Servern zu arbeiten, die dann z.B. nachts synchronisiert werden. Deshalb war meine Frage diesbezüglich eher allgemeinerer Natur. Also gibt es irgendwo Pferdefüße a'la: Replikation funktioniert eigentlich gut, aber...

Wenn man den Router nicht mehr auflegen läßt, wird das nach Bangladesh natürlich ziemlich teuer ;-)

[Andreas Kosch]

Hallo,

in diesem Fall würde ich eine verteilte dreischichtige Anwendung ernsthaft in Betracht ziehen. Zum einen schiebt man dann die Verantwortung auf Microsoft ab, da auf die InterBase-Datenbank nur noch lokal bzw. im LAN vom Application-Server zugegriffen wird. Und zum anderen stellt DCOM/COM+ verschiedene Wege für asynchrone Aufrufe (Message Queue Server bzw. Queued Components) zur Verfügung. Somit darf ein DCOM-Objekt sogar dann erfolgreich aufgerufen werden, wenn keine (!) Verbindung zu diesem Rechner hergestellt werden kann. Sobald die Verbindung wieder steht, werden alle in der Zwischenzeit vorgenommenen Aufrufe im Stapelbetrieb abgearbeitet. Das geht allerdings nur dann, wenn keine sofortigen Rückmeldungen/Rückgabewerte benötigt werden

[Gesine Kuhlmann]

Hallo,

Autsch, dann habe ich das volle Programm und muß mich neben meinen eigenen und Borlands Fehlern auch noch um MS Fehler kümmern ( ogott )

[Andreas Kosch]

Hallo,

so schwierig wird das nicht. Wenn man <i>Windows 2000 Server</i> einsetzen darf und nicht mehr mit NT 4 hantieren muss, ist das Ganze verblüffent transparent und einfach. Allerdings verbirgt sich hinter Three-tier wieder eine völlig andere Philosophie als bei C/S. Und auch der InterBase ist in diesem Bereich infolge es fehlenden OLE DB-Providers nur noch zweite Wahl :-

[Gesine Kuhlmann]

Hallo,

Die Idee möchte ich trotzdem unter "Software-Vorschlaghammer" einordnen. Anwendungen, die sofortige Rückmeldungen erfordern, sollten heute m.E. über eine Infrastruktur verfügen, die diese Möglichkeit von sich aus mit sich bringt.

Das bestechende Merkmal von Interbase, der übersichtliche, geradezu minimalistisch anmutende Installations- und Administrationsaufwand ( von der "Plattformunabhängigkeit" und den geringen Kosten will ich gar nicht sprechen ) geht damit zwangsläufig verloren.

Zwar muß ich nach 2 Jahren NT und folgenden 2 Wochen Win2000 auch bemerken, daß dieses seine Vorgänger, egal wie sie hießen, um Längen schlägt, jedoch habe ich einen Datenbankserver doch lieber, wenn er sich eher gen' Linux orientiert.

Ob alledem insistiere ich nochmal in Richtung Replikation. Funktioniert das: a) ist'n witziges Gimmick, b) im Ansatz, c) kaum, d) passabel, e) gut ?

[Andreas Kosch]

Hallo,

nichts gegen Linux, aber im Datenbankbereich haben sich spätestens seit Februar 2000 die althergebrachten Grundsätze verschoben ;-) <br>
Seit diesem Datum liegt ORACLE mit seinen UNIX-Datenbanken in Punkt der absoluten Transaktionsanzahl pro Zeiteinheit nur noch auf Platz 2, geschlagen vom SQL Server 2000 unter Windows 2000. Und ORACLE hat dies auf seiner Web-Seite auch begründet - unter UNIX/Linux fehlen einfach bestimmte Betriebssystemfunktionen (die in Windows 2000 speziell nachgerüstet wurden), so dass ORACLE nur den kleinsten gemeinsamen Nenner in seinen Datenbanken nutzen kann (was dann in der Endkonsequenz zum Platz 2 führt).

Die Frage der Replikation mit dem InterBase muss ich weitergeben (mangels umfassender eigener Erfahrungen), ich kenne aber jemand, der aussagefähiger ist: <i>Andreas Tengicki</i> (SDCTec Software Development Consult GmbH) zu erreichen über <i>[email protected]</i>