DataSnap, dbexpress und Einzelplatz/Netzwerklösungen mit XE2

[Phoenix]

Lass am besten die Finger von DataSnap.

Mal von ein paar Beispiel-Clicki-Bunti Samples die funktionieren abgesehen wirst Du mit DataSnap 'in the wild' feststellen, dass mal dies, mal jenes nicht funktioniert, und wenn man es dann doch irgendwie hintenrum hingefrickelt hast wirst Du feststellen, dass DataSnap nicht sauber skalieren kann.

Stelle Dir lieber zuerst die Frage, ob Du den massiven(!) overhead eines N-Tier Systems wirklich brauchst und Dir wirklich antun musst. Wenn nicht, dann lass es bleiben.

Wenn Du aber wirklich ein N-Schichten-System aufbauen musst, dann mach es von Hand (deutlich flexibler als DataSnap und unter Garantie Bugfreier) oder benutze Tools die das wirklich beherrschen und nicht nur so tun als könnten sie es, um dann in den entscheidenden Momenten grandios zu versagen.

[cytrinox]

Kannst du die Probleme bzw. was auch immer nicht funktioniert genauer beschreiben?

Ich möchte hauptsächlich folgende Dinge damit erledigen:

- Keine Database-Clientbibliotheken auf den Clients, sondern nur Serverseitig, wobei ich auf dem Server dann die Native Libs per dbexpress verwenden will (fbclient.dll, sqlncli, usw, und nicht wie z.B. ZEOS für MS-SQL irgendwie über ADO hinbiegen).

- Statt zwei TCP Verbindungen (Datenbank + AppServer) nur noch eine, die aber grundsätzlich komprimiert + verschlüsselt ist (beides Dinge, die manche Systeme - z.B. Firebird - nicht direkt anbieten).

- Eine einfache Möglichkeit (verschlüsselt) zwischen einem Client und dem AppServer zu kommunizieren. Bisher habe ich dafür immer ein kleines Protokoll gestrickt (z.B. Binary, Plaintext oder XML, je nach Anforderung) und das über TCP Indy Sockets gemacht. Die gleiche Funktionalität hatte ich mit Datasnap nun aber in ein paar Minuten zusammengklickt.

[himitsu]

Callbacks sind Schrott (auch wenn sie sich in XE2 angeblich ein bissl gebessert haben sollen)

Speicherlecks (auch Dank einiger fehlerhafter und weitverbreiteter Beispiele im Netz)

Vorallem wenn die Verbindung nicht 100% stabil ist, gibt es schöne Nebenwirkungen, da die offenen Verbindungen gerne mal hängen bleiben.

Die automatisch generierten Klientklassen sind Schrott, da man eine getrennte/abgebrochene Verbindung nich wiederverbinden kann, weil die DBXConnection schrottig verwaltet wird (macht man das alles selber, läuft es besser).

Die Dokumentation ist das Schlimmste ... es gibt praktisch keine. (abgesehn von einigen netten Büchern, welche man sich unbedingt kaufen sollte, will man wirklich mehr machen, als die schrottigen Beispiele einem aufzeigen)

~3-5 MB pro Klientverbindung ... da ist der Server schnell voll.

Multithread im Klienten geht nur durch mehrfache Datenverbindungen. (möchte man ein fehlerfreieres Verhalten haben)

Für jeden Clallback-Channel (über den Callbackmanager) eine weitere Datenverbindung.

In XE hatte es praktisch nicht funktioniert mehrere Callbacks an einem Callbackmanager zu registrieren,

Callbacks und Authentifizierung, bzw. eine verschlüsselte Datenübertragung, kannste zusammen vergessen. (der schrottige Callbackmanager verhindert das Zusammenspiel)

usw.

[cytrinox]

Ja was genau ist denn nun Schrott? Diese Meinung ist nicht hilfreich, solange niemand weiß wie du zu der Entscheidung kommst...

Und warum sollte man bei einem Disconnect nicht einfach die TSQLConnection reconnecten? Ich sehe da zumindest von der Codestruktur her grad keine Probleme, wirklich tief durch die Units hab ich mich jetzt aber noch nicht durchgeklickt.

[himitsu]

Bei meinem Streßtest haben sich am Ende durchschnittlich über 80% der Callbacks verabschiedet (reagierten einfach nicht mehr), bei Vielen kamen nichtmal alle Messages an.

Da die (internen) DBXCommands "standardmäßig" nur am Anfang erstellt werden, bei der ersten Benutzung, bekommen sie es nicht mit, wenn die SQLConnection neu verbunden wurde.
Für die DBXConnection enthalten sie dann noch die alten Objektzeiger, zur alten und nicht mehr existierenden DBXConnection ... die Folge sind Exceptions.
Ein Rücksetzen ist nicht vorgesehn. Meine einzige Lösung, für die automatisch generierten Klientklassen > das ganze Datenmodul freigeben und neu erstellen.

Bricht die Verbindung zusammen (z.B. Netzwerkproblem) dann bekommt das der Server und der Klient nicht mit.
Die Connection Der Channel bleibt im Server erhalten > Speicherleck.

Werden dabei registrierte Callbackverbindungen getrennt, ohne daß sie sich ordentlich abmelden konnten, bleiben sie im Server zurück.
Ein Runterfahren des Servers kannst'e dann vergessen, da er dabei oftmals hängen bleibt.

Das Neustarten des Servers kannst'e vergessen, ohne daß danach alle Klienten ebenfalls neu gestartet werden müssen. (genauso, wie bei einer getennten Verbindung)




Um die Verbindungsprobleme zu minimieren: (Lösung für die automatischen Klassen)
- keine Heavyweight Callbacks (die kleinen Callbacks, wärend eines Funktionsaufrufes ausgeschlossen)
- die Verbindung nach jedem Funktionsaufruf trennen (oh, geht ja nicht, ohne das Datenmodul neu zu machen)
- bei einem Verbindungsproblem das Datenmodul zerstören und ein Neues erstellen

Und alleine die 3 Punkte wiedersprechen IMHO einem professionellen Einsatz.





Durch eine standardmäßig auf Localhost festgelegte Verbindung, "lokale" Tests auf unserem Server und durch eine mangelnde Dokumentation hatten wir uns einige nette Problemchen eingehandelt, welche sich erst im realen Einsatz (beim Kunden) zeigten ... das kommt super an

Wir haben es jetzt seit knapp einem Jahr im Einsatz und immernoch nicht alle Probleme beseitigt.
Zum Glück wurden inzwischen einige Dinge gelöst (mehr/neue Infomationen (Bücher) sind im Umlauf, aber nicht die von Emba).

[cytrinox]

Danke für die ausführliche Beschreibung, jetzt kann ich deinen Standpunkt auch besser nachvollziehen.

Ich möchte mir aber doch gern die Zeit nehmen und unter XE2 das alles mal probieren & debuggen und auch Netzwerkprobleme zu simulieren. Ergebnisse würde ich hier ergänzen.

Daher wäre es super wenn wir die ursprünglichen Fragen noch klären könnten damit es nicht schon daran scheitert