DataSnap Client connection über FireDAC

[jaenicke]

Wir nutzen DataSnap ebenfalls. Abbrechende Verbindungen verwalten wir selbst. Sprich wir haben einen Wrapper um die Clientmethoden, die die Verbindung wieder aufbauen, wenn der Aufruf durch einen Verbindungsabbruch fehlschlägt.

Der Transfer von Datasets über FireDACJSONReflect funktioniert sehr gut und ist gerade bei vielen kleinen Datenbanktabellen um ein vielfaches schneller als vorher via DBX. Ich hoffe, dass da noch mehr kommt, aber gut nutzbar ist das auf jeden Fall.

Da serverseitig eigene Sessions auch das Datenbankhandling übernehmen, ist auch dort ein Verbindungsabbruch kein Problem solange die Session beim Reconnect noch da ist. Da man bei FireDACJSONReflect die Verbindung zwischen den Komponenten selbst regelt, macht DataSnap da auch keinen Strich durch die Rechnung wie leider an manchen anderen Stellen.

Wichtig beim Reconnect:
Die Clientmethoden-Klasse muss neu erstellt werden, ansonsten funktioniert diese danach nicht mehr...
Vielleicht ist das das Problem gewesen, auf das du gestoßen warst.

[Uwe Raabe]

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

[Kostas]

Danke Sebastian für den Hinweis.

Ich fange jetzt wirklich frisch an und versuche mich durch die Tuts und Dokus.
Dein Hinweis kann ich noch nicht werten, ich bin noch nicht so weit.
Möglicherweise meinst du das:

Aus den aktuellen Tut: http://docwiki.embarcadero.com/RADSt...Base-Tutorial)

Delphi-Quellcode:

procedure TfrClientMain.Button3Click(Sender: TObject);
var
  myServer: TUn_ServerModuleClient;
  von,bis: TDateTime;
begin
  SQLConnection1.Open;

  myServer := TUn_ServerModuleClient.Create(SQLConnection1.DBXConnection);
  try
    Label1.Caption := myServer.callStoredProcedureAuswertung(StrToDateTime(Edit1.Text),StrToDateTime(Edit2.Text));
  finally
    if SQLConnection1.Connected
    then SQLConnection1.close;
    myServer.free;
  end;

end;

Meinst du das die Instanz von "myServer" nach einem Abbruch neu erzeugt werden soll?
In diesem Fall wäre das recht einfach. Ich nutze hier eine Methode "callStoredProcedureAuswertung" die der DataSnapServer bereitstellt. Es ist aber
auch so dass der Client DataSets konsumiert die über DataSetProvider-ClientDataSet
bereitgestellt werden. Auf der Form gibt es auch eine DSProviderConnection dessen Connection
ich zumindest zur Designtime nicht disconnecten kann.

Sorry für die unqualifizierte Beschreibung, wie gesagt, ich fange wieder frisch an.

Gruß Kostas

[jaenicke]

Zitat von Kostas:

Meinst du das die Instanz von "myServer" nach einem Abbruch neu erzeugt werden soll?

Ja, genau.

Zitat von Uwe Raabe:

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Welchen meinst du?

Callbacks habe ich zumindest aus Thin Clients durch erneute Verbindungsversuche wiederherstellen können ohne dass ich etwas geändert hätte.

[Uwe Raabe]

Zitat von jaenicke:

Zitat von Uwe Raabe:

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Welchen meinst du?

Callbacks habe ich zumindest aus Thin Clients durch erneute Verbindungsversuche wiederherstellen können ohne dass ich etwas geändert hätte.

Den Patch brauchte ich in einer XE3 App und ich habe es unter XE6 noch nicht wieder probiert, denke aber es ist dort immer noch so.

Kurz: Bei verbundenem Client den Server neu starten. Nun funktionieren die Callbacks nicht mehr und der Client kann die auch nicht mehr registrieren. Das lässt sich nur mit einem Neustart des Clients beheben (genauer mit dem Neuerzeugen des CallbackManagers).

Lang: In TDSClientCallbackChannelManager.CloseClientChannel wird das interne Feld FStopped gesetzt, wenn der Server die Verbindung beendet. Dabei werden aber die Callbacks nicht freigegeben. Ruft man dann TDSClientCallbackChannelManager.CloseClientChannel auf, ist der ExcuteRemote-Aufruf zum einen vollkommen überflüssig (die Verbindung ist ja definitiv weg) und läuft zum anderen in einen Timeout (kostet unnütz Zeit). Das nachfolgende FLocalCallbackRepo.Clear und das Anpassen der Statevariablen wird nicht mehr aufgerufen. Die Callbacks bleiben also im Dictionary und man kann Sie somit nicht mehr neu anlegen (RegisterCallback sieht, die sind schon da und gibt false zurück). Die alten Callbacks funktionieren aber nicht mehr, weil sie beim Server nicht mehr registriert sind (der wurde ja neu gestartet).

Der Patch besteht im Wesentlichen darin, bei FStopped das ExecuteRemote zu überspringen und trotzdem das FLocalCallbackRepo.Clear aufzurufen. Bei XE3 liegt der Code in Datasnap.DSHTTPCommon und bei XE6 in Datasnap.DSCommon.

[jaenicke]

FStopped finde ich nicht, ich vermute du meinst State auf Stopped? Das Problem ist dann aber klar, ja.
Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Jetzt wo du es sagst, kann ich mich auch erinnern, dass ich an der Stelle schon einmal ein Problem hatte, ich hatte es mir nur nicht genauer angeschaut.

Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

[Uwe Raabe]

Zitat von jaenicke:

FStopped finde ich nicht, ich vermute du meinst State auf Stopped?

FStopped ist ein Feld von TDSClientCallbackChannelManager und wird in NotifyChange gesetzt. Da es strict private ist, lässt sich das leider auch nicht mit einer abgeleiteten Klasse fixen.

Zitat von jaenicke:

Der Code in CloseClientChannel sieht in XE3 und XE6 identisch aus.

Bis auf die Tatsache, daß in XE3 die lokale Variable Status nicht initialisiert wird und damit einen unbestimmten Wert enthält wenn State <> ctsStarted ist. In XE6 wird sie mit False vorbelegt, was meiner Meinung nach ungünstig ist, aber das ist vielleicht auch Geschmackssache. Ich finde es intuitiver, wenn auch bei State <> ctsStarted ein CloseClientChannel mit true durchläuft und der State hinterher auf ctsStopped steht, insbesondere wenn der State vorher auf ctsFailed stand. Wichtig ist aber, daß Status bei FStopped auf True gesetzt wird, damit auch aufgeräumt wird.

Zitat von jaenicke:

Das Problem ist dann aber klar, ja.Gibt es dazu schon einen QC Eintrag? Ich konnte nämlich eben bei einer schnellen Suche keinen finden.

Ich muss zu meiner Schande gestehen, daß ich es versäumt habe, einen simplen Testfall aufzubereiten. Takahashi san ist da bekannterweise etwas anspruchsvoll. Ich gelobe aber Besserung.

[Kostas]

Zitat von Uwe Raabe:

Erganzend dazu: Der ClientCallbackManager braucht einen kleinen Patch, damit er nach einem Verbindungsabbruch wieder funktioniert.

Das ist doch sehr interessant. Danke für den Hinweis Uwe.