Sperrung von Datensätzen über mehrere Standorten

[hsg]

Hallo DP,

die grobe Aufgabenbeschreibung lautet so:
ich soll die mehrmalige Bearbeitung eines Datensatzes über mehrere Standorte hinweg verhindern, das Lesen des Datensatzes soll dabei aber noch möglich sein.

Die Rahmenbedingungen dazu sind: wir haben drei Standorte, die über Standleitungen miteinander Kommunizieren. In allen drei Standorten gibt es einen Datenbank-Server mit Advantage Database Server (8.1) mit den entsprechenden Datenbanken. An allen drei Standorten sind die Daten aller Standorte vorhanden (wird durch die Replikation des Datenbank-Servers sichergestellt).

Nun ist es ja theoretisch möglich, dass an Standort A und B der Datensatz X geöffnet und bearbeitet wird. Dieses soll ich nun verhindern, stellt sich nur die Frage wie?

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird. Hat aber eine Menge Probleme und Nachteile, hat irgendwer andere Vorschläge?

[mkinzler]

Zitat:

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird.

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

[sirius]

Zitat:

Zitat von mkinzler

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

Genau das war auch mein erster Gedanke. Hier müsste man wahrscheinlich direkter über Trigger gehen.

[ManuelR]

Zitat:

Die Rahmenbedingungen dazu sind: wir haben drei Standorte, die über Standleitungen miteinander Kommunizieren. In allen drei Standorten gibt es einen Datenbank-Server mit Advantage Database Server (8.1) mit den entsprechenden Datenbanken. An allen drei Standorten sind die Daten aller Standorte vorhanden (wird durch die Replikation des Datenbank-Servers sichergestellt).

Hallo

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Lösung: nur 1 Datenbankserver, die 2 anderen Standorte greifen remote z.B. über Terminal-Sessions drauf zu.


Viele Grüsse

[hsg]

Zitat:

Zitat von mkinzler

Zitat:

Der erste Ansatz wäre ein zusätzliches Datenbank-Feld, das true ist, wenn der Datensatz an irgendeinem Standort geöffnet wird und beim Verlassen wieder auf false gesetzt wird.

Die Frage wäre hierbei nur, ob die Replikation schnell genug ist, um so eine mehrfache Bearbeitung zu verhindern.

Trigger über mehrere Standorte? Wie würde sowas gehen?

Zitat:

Zitat von ManuelR

Hallo

Wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Lösung: nur 1 Datenbankserver, die 2 anderen Standorte greifen remote z.B. über Terminal-Sessions drauf zu.


Viele Grüsse

Weil die Standleitungen öfters mal weg sind und in einem solchen Fall in den einzelnen Werken kein weiteres Arbeiten mehr möglich wäre.
I.d.R. sollte das Bearbeiten von zweimal desselben Datensatzes nicht auftreten, aber es kann eben auch nicht ausgeschlossen werden => Forderung der extrem hohen Sicherheit :evil:

Ich persönlich vermute eigentlich, dass das Problem nie auftreten wird (weil jeder Sachbearbeiter eben seine eigenen Daten bearbeitet) aber mein Chef sieht das etwas anders :?

[joachimd]

Zitat:

Zitat von ManuelR

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Wahrscheinlich wegen Geschwindigkeit und Ausfallsicherheit. Und hier haben wir dann gleich ein Problem: Wenn die Daten editierbar sein sollen, auch wenn die Standleitung ausfällt, so dürfen die anderen Rechner nicht eine Zwangssperrung bekommen, weil sonst das ganze System steht!
Ich würde das mehrfache Editieren zulassen und über Konflikttrigger die Business Rules realisieren (zB einen Zeitstempel mitführen, der neueste Datensatz gewinnt...oder im Konfliktfall die entsprechenden Datensätze mitloggen und zur wiederbearbeitung vorlegen..oder, oder, oder).

[hsg]

Zitat:

Zitat von joachimd

Zitat:

Zitat von ManuelR

wieso sind die Datenbanken 3-fach vorhanden, wenn die Standorte sowieso über Standleitungen verbunden sind ?

Wahrscheinlich wegen Geschwindigkeit und Ausfallsicherheit. Und hier haben wir dann gleich ein Problem: Wenn die Daten editierbar sein sollen, auch wenn die Standleitung ausfällt, so dürfen die anderen Rechner nicht eine Zwangssperrung bekommen, weil sonst das ganze System steht!
Ich würde das mehrfache Editieren zulassen und über Konflikttrigger die Business Rules realisieren (zB einen Zeitstempel mitführen, der neueste Datensatz gewinnt...oder im Konfliktfall die entsprechenden Datensätze mitloggen und zur wiederbearbeitung vorlegen..oder, oder, oder).

Die Konflikttrigger werden zusätzlich benötigt. Das Problem liegt aber eher weniger an dem Dateninhalt, sondern was mit dem Datensatz u.U. passieren kann: Der Datensatz könnte z.B. ein Angebot (bzw. Auftrag) sein, das abgegeben werden soll: Mitarbeiter A geht in Druckvorschau und bevor er das Angebot ausdruckt oder per Email verschickt, geht er erst einmal zu Mittag.
In der Zwischenzeit kümmert sich der Mitarbeiter B um das Angebot (z.B. weil der Kunde anruft und drängelt) und ändert was daran, druckt es aus und verschickt es.
Nach dem Mittag kommt A wieder, druckt Angebot aus und verschickt es. Folge: der Kunde erhält zwei Angebote mit gleicher Nummer und Änderungsindex und weiss nicht mehr was das soll.

Wie gesagt: ich halte dieses Scenario für relativ unwahrscheinlich, aber mein Chef will das eben so :cry:

[mkinzler]

Du kannst das szenario auch so ändern, das alle auf der zentralen DB arbeiten, welche an den Standorten repliziert wird. der Client überprüft dann beim Start ob zentrale Db erreichbar sonst Rückfall auf replizierte DB

[hsg]

Zitat:

Zitat von mkinzler

Du kannst das szenario auch so ändern, das alle auf der zentralen DB arbeiten, welche an den Standorten repliziert wird. der Client überprüft dann beim Start ob zentrale Db erreichbar sonst Rückfall auf replizierte DB

Dagegen spricht die Geschwindigkeit der Standleitungen (eine ist zur Zeit nur 128K schnell, versuchen die gerade auf 2MBit hochzurüsten, ob das aber klappt weiss noch nicht mal die T-Kom).

[mkinzler]

Für eine SQL-Datenbankverbindung sollte das eigentlich reichen.

[Mavarik]

Wenn die Standleitung weg ist kannst Du doch auch nicht mehr sperren, also muss doch sowieso eine bessere Lösung her, oder?

Frank :coder:

[sirius]

Varaiante 1:
Da kann man nur einzelne Arbeitschritte in unterschiedliche Kategorien einstufen. Sodass Aktionen aus Kategorie 1 (Briefe verschicken an Kunden) nur durchführbar sind, wenn alle 3 Datenbanken verfügbar sind und damit durch einen Lcient oder durch die Datenbanken selber oder... vorherabgeglichen und damit freigegeben werden können.


Varainte 2:
-Festlegen, dass nur Datensatz A (=Kunde xyz) auf Server 1 der einzig Richtige ist (und Datensatz B auf Server 2; je nachdem wo es wichtiger ist).
-Diese Informationen auf allen 3 Servern hinterlegen. also, dass jeder weis, auch wenn er grad keine Verbindung zu Server 1 hat, dass nur dort die richtigen Daten liegen und er eine (womöglich falsche) Kopie hat.
Dadurch kann jemand, der auf Server 2 arbeitet sehen, dass er den einen Datensatz unbedingt mit Server 1 vorher (vorm Versenden) abgleichen muss.

[hsg]

Zitat:

Zitat von mkinzler

Für eine SQL-Datenbankverbindung sollte das eigentlich reichen.

Bei 120 Usern die intensiv mit dem Programm arbeiten? Ich finde das schon alleine manchmal sehr träge.
Meine Applikation muss sich mit der Geschwindigkeit von mehreren Dos-Programmen messen, da sieht es lokal schon manchmal traurig aus (wobei ich auch wesentlich mehr Information auf einmal zur Verfügung stelle als die DOS-Programme und versucht habe mich dabei nur auf das Wesentliche zu konzentrieren, die GL will dort manchmal noch viel mehr Möglichkeiten haben)

Zitat:

Zitat von Mavarik

Wenn die Standleitung weg ist kannst Du doch auch nicht mehr sperren, also muss doch sowieso eine bessere Lösung her, oder?

Frank :coder:

Wenn du eine hast: her damit!

[kalmi01]

Zitat:

Wenn die Standleitung weg ist kannst Du doch auch nicht mehr sperren, also muss doch sowieso eine bessere Lösung her, oder?

Wenn du eine hast: her damit!

Ich mache soetwas ähnliches ungefähr so:
1.) Server "unterhalten" sich per UDP untereinander (Jeder mit Jedem)
2.) Sobald 1 Server nicht mehr mit den anderen "spricht" schalten alle die Protokolierung ein
3.) Wenn wieder alle online sind, gleichen sie untereinander die Protokolle ab
4.) werden Transaktionen an gleichen Datensätzen festgestellt ==> Warnmeldung an den Anwender

In den Protokollen werden relevante Transaktionen festgehalten, z.B. wenn der Datensatz verändert wurde.
Jeder Server vergleicht die Protokolle der anderen beiden mit seinem eigenen.

UDP, weil es einfach ein Packet versendet, ohne sich drum zu kümmern, ob es ankommt.
Das ist wichtig, sonst wird bei Verlust der Verbindung der Server ausgebremst, weil er
versucht seine Packete los zu werden.

[hsg]

Zitat:

Zitat von kalmi01

Ich mache soetwas ähnliches ungefähr so:
1.) Server "unterhalten" sich per UDP untereinander (Jeder mit Jedem)
2.) Sobald 1 Server nicht mehr mit den anderen "spricht" schalten alle die Protokolierung ein
3.) Wenn wieder alle online sind, gleichen sie untereinander die Protokolle ab
4.) werden Transaktionen an gleichen Datensätzen festgestellt ==> Warnmeldung an den Anwender

In den Protokollen werden relevante Transaktionen festgehalten, z.B. wenn der Datensatz verändert wurde.
Jeder Server vergleicht die Protokolle der anderen beiden mit seinem eigenen.

UDP, weil es einfach ein Packet versendet, ohne sich drum zu kümmern, ob es ankommt.
Das ist wichtig, sonst wird bei Verlust der Verbindung der Server ausgebremst, weil er
versucht seine Packete los zu werden.

Was du machst, macht für mich die Replikation des Datenbank-Servers. Bei Kollisionen auf den Daten gibt es entsprechende OnConflict-Trigger die dann von mir irgendwie behandelt werden müssen.
Dies ist aber nicht mein Problem.

Zitat:

Zitat von sirius

Varainte 2:
-Festlegen, dass nur Datensatz A (=Kunde xyz) auf Server 1 der einzig Richtige ist (und Datensatz B auf Server 2; je nachdem wo es wichtiger ist).
-Diese Informationen auf allen 3 Servern hinterlegen. also, dass jeder weis, auch wenn er grad keine Verbindung zu Server 1 hat, dass nur dort die richtigen Daten liegen und er eine (womöglich falsche) Kopie hat.
Dadurch kann jemand, der auf Server 2 arbeitet sehen, dass er den einen Datensatz unbedingt mit Server 1 vorher (vorm Versenden) abgleichen muss.

Die Lösung hört sich schon mal nicht schlecht an, innerhalb eines Standortes wird dann noch der Datensatz gelockt damit gleiche Zugriffe innerhalb eines Standortes nicht gehen......
Muss ich mal weiter durchdenken und mit meinem Chef bequatschen, hat mir aber schon mal viel weiter geholfen.
Für weitere Ideen bin ich natürlich auch noch offen
:dp: