Zugriff mehrerer User auf eine Datei

[Jean]

Hallo an alle Spezialisten,

vielleicht hat jemand eine gute Idee.

Ich möchte, dass ein Zugriff auf eine Datei im Netzwerk (Zugriff schreibend, lesend) von mehreren Usern gleichzeitig möglich ist.
Sicherlich könnten jetzt Vorschläge kommen, das ganze sicher über eine Datenbank zu realisieren. Diese Option sollte wirklich nur das allerletzte Hintertürchen sein, falls es wirklich nicht anders zu lösen ist.

In die Datei (ähnlich vielleicht wie bei einer *.ini) werden nur Benutzername und ein Wert geschrieben. Dieser Wert soll dann über die Anwendung gepollt und allen anderen Nutzern angezeigt werden (vergleichbar mit einer Highscore-Liste).

Bin über jeden geistigen Eisprung dankbar.

LG, Jean

[mkinzler]

Ich würde eine Datenbank mit embedded Zugriff verwenden, wie z.B. FireBird embedded, SQLite, MSSQL compact, ...
Du brauchst so kein DBMS installieren und brauchst dich trotzdem nicht um dir notwendige Synchronisierung des Dateizugriffs zu kümmern.

[sx2008]

Das ist eigentlich kein Problem; du muss nur angeben, dass die zentrale Datei von allen Prozessen zum Lesen und zum Schreiben geöffnet werden darf:

Delphi-Quellcode:

var
  fs : TFileStream;
begin
  fs := TFileStream.Create('N:\userlist.dat', fmOpenReadWrite or {alle dürfen lesen/schreiben}fmShareDenyNone);
  try
  finally
    fs.Free;
  end;
end;

Das Problem ist jetzt, dass mehrere Prozess gleichzeitig die Datei verändern können.
Du brauchst innerhalb der Datei eine Struktur, die verhindert das Prozess B das überschreibt was Prozess A gerade reingeschrieben hat.

Es gibt auch noch einen zweiten, sicheren Weg.
Hierbei darf immer nur ein Prozess auf die Datei zugreifen.

Delphi-Quellcode:

fs := TFileStream.Create('N:\userlist.dat', fmOpenReadWrite or fmShareExclusive);

Das Prinzip geht so:
ein Prozess öffnet die Datei exklusiv, liest den ganzen Inhalt und schreibt seinen Score und schliesst die Datei wieder.
Zwischen Öffnen und Schliesen sollte möglichst wenig Zeit vergehen.
Wenn eine Datei schon in Bearbeitung ist kann ein weiterer Prozess diese solange nicht öffnen.
Mit einem Timer versucht man es einfach mehrfach, bis man Erfolg hat.
Erfahrungswerte: das Prinip der exklusiv gesperrten Datei funktioniert gut auch bei 50 Rechner.
Bei voller Netzwerkauslastung kann ein Prozess aber auch schon mal 2 Sekunden blockiert sein, weil die Datei ständig von anderen Prozess geöffnet ist.

[Jean]

Hallo,

vielen Dank für Eure Antworten.
Ich werde mich auf jeden Fall mit beiden Themen beschäftigen. Danke für die Tipps.

LG, Jean

[Perlsau]

Zitat:

Zitat von Jean (Beitrag 1220894)

Ich möchte, dass ein Zugriff auf eine Datei im Netzwerk (Zugriff schreibend, lesend) von mehreren Usern gleichzeitig möglich ist.
Sicherlich könnten jetzt Vorschläge kommen, das ganze sicher über eine Datenbank zu realisieren. Diese Option sollte wirklich nur das allerletzte Hintertürchen sein, falls es wirklich nicht anders zu lösen ist.

Das geht nicht, weil moderne Betriebssysteme verhindern, daß dieselbe Datei gleichzeitig von mehreren Usern offen gehalten werden kann. Eine scheinbare Lösung böte eine Stringlist, doch entsteht dabei ein anderes Problem: Stell dir vor, User1 liest die Datei in den Speicher ein (z.B. via Memo.Lines.LoadFromFile) und fügt der eingelesenen Liste einen neuen Wert hinzu. Währenddessen liest auch User2 diese Datei und addiert ebenfalls einen neuen Eintrag: User2 liest die Datei, bevor User1 sie zurückgeschrieben hat. Während User2 seinen Highscore einträgt, schreibt User1 die Stringliste zurück. Danach schreibt User2 seine Stringliste zurück und überschreibt somit die von User1 gemachten Änderungen, da er die ja beim Einlesen noch nicht kannte.

Fazit: Das ist keine brauchbare Lösung.

[Perlsau]

Zitat:

Zitat von sx2008 (Beitrag 1220897)

Das ist eigentlich kein Problem; du muss nur angeben, dass die zentrale Datei von allen Prozessen zum Lesen und zum Schreiben geöffnet werden darf:

var
fs : TFileStream;
begin
fs := TFileStream.Create('N:\userlist.dat', fmOpenReadWrite or fmShareDenyNone);
try
finally

Und du meinst, dabei entstehen keine Probleme mit dem Überschreiben von Inhalten, wenn mehrere User gleichzeitig dieselbe Datei bearbeiten und verändern? Es geht ja nicht nur um's lesen, sondern auch um's zurückschreiben ...

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1220895)

Ich würde eine Datenbank mit embedded Zugriff verwenden, wie z.B. FireBird embedded, SQLite, MSSQL compact, ...
Du brauchst so kein DBMS installieren und brauchst dich trotzdem nicht um dir notwendige Synchronisierung des Dateizugriffs zu kümmern.

Äh - Firebird Embedded erlaubt nur einen Zugriff zur selben Zeit. Besteht bereits eine Connection, wird jeder Versuch, eine weitere Connection zu erstellen, abgewiesen. Außerdem müssen bei FB-embedded die DB-Dateien im selben Verzeichnis liegen wie die Anwendung. Wieso also embedded?

Besser wäre hier doch ein Server, der von allen erreichbar ist, oder eine Access-Datenbank, die kann man sogar auf einem Fileserver oder einer Netzwerkplatte betreiben kann. Ich hab das mal bei einem Verein realisiert, der keinen Netzwerkserver hatte, sondern nur eine Netzwerkplatte. Funzt bis heute einwandfrei, obwohl ich Timer einbauen mußte, um regelmäßig gewisse Tabellen abzufragen. Das macht aber bis heute so wenig Last, daß sich noch keiner beschwert hat.

[mkinzler]

Zitat:

Äh - Firebird Embedded erlaubt nur einen Zugriff zur selben Zeit. Besteht bereits eine Connection, wird jeder Versuch, eine weitere Connection zu erstellen, abgewiesen.

Ab 2.5 basiert die embedded nicht mehr auf der SuperServer, sondern der neuen SuperClassic Variante.

Zitat:

Außerdem müssen bei FB-embedded die DB-Dateien im selben Verzeichnis liegen wie die Anwendung. Wieso also embedded?

Nein die Datei muss nicht im selben Verzeichnis liegen.

Zitat:

Besser wäre hier doch ein Server, der von allen erreichbar ist,

Das wäre das Beste, ist aber nicht immer möglich und bedeutet Mehraufwand.

Zitat:

oder eine Access-Datenbank

Lieber nicht, da Access meiner Efahrung nach große Probleme bei Multiuserzugriff hat ( defekte Datenbanken usw.) zudem ist der Installationsaufwand bei den Client höher als bei anderen Lösungen.

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1220905)

Ab 2.5 basiert die embedded nicht mehr auf der SuperServer, sondern der neuen SuperClassic Variante.

Da bin ich offenbar nicht auf den Laufenden :o

Zitat:

Zitat von mkinzler (Beitrag 1220905)

Nein die Datei muss nicht im selben Verzeichnis liegen.

Auch dieses Feature seit 2.5? Muß ich heute abend mal testen ...

Zitat:

Zitat von mkinzler (Beitrag 1220905)

Lieber nicht, da Access meiner Efahrung nach große Probleme bei Multiuserzugriff hat ( defekte Datenbanken usw.)

Wie gesagt, ich hatte damit noch keine Probleme. Das ganze System (App und DB) ist so eingerichtet, daß jeder User lediglich seine eigenen Einträge bearbeiten kann. Es geht dabei in der Hauptsache um Terminvereinbarungen: jeder eingeloggte User kann natürlich für andere Mitarbeiter Termine vereinbaren, aber nur, wenn der betreffende User nicht eingeloggt ist, was bedeutet, er ist nicht im Haus und kann diesen Termin daher nicht selbst vereinbaren. Ändern kann dann wiederum nur der Mitarbeiter, der den Termin hat, diesen Eintrag. Es kommt zudem, wie mir berichtet wurde, nur äußerst selten vor, daß ein Mitarbeiter für einen anderen einen Termin vereinbart.

Wie gesagt, es funktioniert jetzt bereits seit über drei Jahren ohne Probleme.

Zitat:

Zitat von mkinzler (Beitrag 1220905)

zudem ist der Installationsaufwand bei den Client höher als bei anderen Lösungen.

Naja, das ist ein anderes Problem. In meinem Fall wurde das natürlich von mir persönlich eingerichtet und den Leuten erklärt. Und für mich war das kein nennenswerter Aufwand (das Entwickeln dagegen schon).

[Aphton]

Bei einer Highscore dürftest du das Problem mit dem "dirty writing" haben, sofern derjenige, der schreibt, auch die Logik ausführt (einsortieren in die Highscore Liste). Dafür muss es einen wechselseitigen Ausschluss geben.
Für soetwas dürfte das Fassade-Pattern angebracht sein - eine Schnittstelle, die das Eintragen übernimmt.