Konzepte für gemeinsames Arbeiten an einer Datei ohne Server

[Harry Stahl]

Ehrlich gesagt war ich weniger interessiert an Gedanken um Viren, pro und contra von lokaler oder Server-Lösung, mir ging es wirklich nur darum, ob da jemand sich schon mal kluge Gedanken gemacht hat um so eine Art technisches Protokoll, bzw. was man zu beachten hat.

Z.B: Öffnet ein User A die Datei, macht es Sinn, dann in die Datei eine Info aufzunehmen, dass er die Datei geöffnet hat, so dass User B darüber unterrichtet wird. Schreibt man es dann in die Datendatei selber oder in eine zusätzliche Datei "ManAtWork.info"

Ich glaube, eine solche Lösung zusätzlich anzubieten wäre gut. Denn einige Leute (die evtl. nicht so IT-Affin sind) erwarten quasi, dass auch mehrere Anwender zur gleichen Zeit mit einer Datei arbeiten können.

Was mir im Moment so vorschwebt wäre folgendes (sollte noch vorweg schicken, dass die Datei immer vollständig in den Arbeitsspeicher geladen wird, um sie zu bearbeiten):

User A öffnet die Datei und arbeitet an der Datei im "Gruppenmodus" (quasi neue Variante zum "Netzwerkmodus" und "Einzelplatzmodus").

* Im Gruppenmodus wird jede Änderung an der Datei sofort gespeichert.

* Nun öffnet User B die Datei, letztlich im aktuellen Zustand, da ja jede Änderung von User A sofort gespeichert.

* Nun macht User A eine weitere Änderung an der Datei, die direkt gespeichert wird.

* Programm des Users B bekommt das sofort mit, weil es vom System über die Änderung der Datei informiert wird (zumindest unter Windows ja kein Problem).

* Darum lädt User B die geänderte Datei temporär in den Arbeitsspeicher und das Programm vergleicht die einzelnen Datensätze, lokalisiert den geänderten Datensatz (kein Problem, für jede Änderung gibt es einen Timestamp je Datensatz) und übernimmt die Änderung in den eigenen geladenen Datenbestand.

* Wenn User B nun eine Änderung vornimmt, läuft es genau wie zuvor geschrieben, halt nur umgekehrt (User A wird unterrichtet und aktualisiert seinen Datenbestand).

So kann das ja eigentlich Lustig hin und her gehen, der einzige evtl. problematische Fall wäre die Situation, wo beide Anwender zu gleichen Zeit am gleichen Datensatz arbeiten. In der Netzwerklösung lasse ich das nicht zu, da wird die Bearbeitung sofort gesperrt, wenn ein User anfängt einen Datensatz zu bearbeiten.

Es wäre also zu überlegen, ob man sich hier ein ersatzweises Locking ausdenkt oder ob man die Inhalte der Felder automatisch "merged" und nur, wenn die User am gleichen Feld was verändert haben, einen Konfliktlösungsdialog anzeigt (was nicht das Problem wäre, da ich sowieso schon eine Abgleichfunktion im Programm habe, wenn Außendienstmitarbeiter offline eine Datei bearbeiten und Änderungen hinterher wieder ins Netz einspielen wollen).

Hier habe ich halt keine so richtige Idee für ein ersatzweises locking für einen zu bearbeitenden Datensatz und glaube auch letztlich, dass es zuviel Aufwand wäre hier was einzuführen. Denn wenn nur 2-4 Leute in einer kleinen Firma mit einer Adressdatei arbeiten (oder ein einzelner User von verschiedenen Rechnern aus), wie oft wird das schon vorkommen, dass jemand zur gleichen Zeit ausgerechnet am gleichen Feld was ändert?

[Codehunter]

@Harry: Über diese Dinge haben sich viele kluge Köpfe den selbigen zerbrochen. Vor 20..30 Jahren. Am Anfang (an den ich mch noch erinnern kann) war da sowas wie dBase und Foxpro. Es gab da viele Experimente mit konkurrierenden Zugriffen. Novell hat da viel Geld versenkt bis das bei Netware dann mal halbwegs funktioniert hat. Ich war auch mal an so einem Thema dran, im Zusammenhang mit SQLite. Am Ende stellte sich heraus, dass man sich da noch so viele Gedanken machen kann, das Problem liegt woanders.

Nämlich beim Netshare und dem Betriebssystem, das es anbietet. Wenn das kein Realtime-OS ist sondern immer schön cached und verzögert, kannst du das mit dem Locking gar nicht sicher hinbekommen. Denn selbst wenn Client A zuerst kommt und locken will, Client B aber zufällig am Server auf einem CPU-Core landet der grad weniger zu tun hat und daher schneller am Ziel ist, führt deine Anwendung auf beiden Rechnern den Codepfad aus, der für nicht-gelockte Dateien gilt. Und schon hast du eine geschmeidige Dateikorruption.

Vor 20 Jahren war die Lösung schon die selbe, wie heute auch noch: Ohne eine Softwarekomponente, welche auf der Servermaschine die Zugriffe steuert, geht das vor den Baum. SQL-Server aller Couleur sind da eine Möglichkeit.

Die Frage, ob lokaler Serverdienst oder Clouddienst, das steht auf einem anderen Blatt. Für beides gibt es Pro und Contra, die von Kunde zu Kunde differieren können.

[TigerLilly]

Neben Concurreny ist der Stromausfall dein großer Feind. Und User, die Daten bearbeiten + dann Mittagessen gehen ohne zu speichern.

Müsste ich hier über eine Lösung nachdenken, würde ich in Richtung verteilte Systeme denken. Jeder User hat alle Daten im Zugriff und per Messaging wird im Hintergrund synchronisiert. Da nicht alle Clients immer am Netz sind, wird es wohl eine Art Änderungsprotokoll geben, von dem sich die Clients immer den relevanten Teil holen.

Aber da bist du auch schon sehr nahe an dem, was MSSQL mit Replikation macht. Bzw hab ich ECHO von TMS ja schon mal angesprochen.

[Rollo62]

Ich würde das per kleinem PHP RestService machen, mit Slim, Laravel o.ä.

[pertzschc]

@Harry: Es gab mal Groove, das hatte diese Fragen gelöst.

[Schokohase]

Zitat von pertzschc:

@Harry: Es gab mal Groove, das hatte diese Fragen gelöst.

Nein, hat es nicht ...
Wikipedia: Microsoft Groove - Nachteile

Zitat:

Groove benötigt einen Relay über Groove-Networks-Server, deshalb kein reines P2P.

Also auch hier wird ein Server benötigt.

Und genau darauf wird es immer wieder hinauslaufen. Ein zentrales Element, dass die Oberaufsicht hat.

[freimatz]

<Haarspaltermodus>Nicht immer. Z.B. Bitcoin kann es auch ohne, da geht es dann um Mehrheiten.</Haarspaltermodus> Aber den Aufwand ...