hi,
ich benutzte die TJvSimpleXML komponente um in xml dateien zu schreiben und zu lesen.

nun möchte ich mein Programm an mehreren Arbeitsplätzen verteilen und den Mitarbeitern das schreiben auf eine XML-Datei ermöglichen die sich im Netzwerk befindet.
Eine Datenbanklösung fällt leider weg, da ich auf dem Server auf dem der Ablagepfad existiert nicht verändert werden darf. Lediglich Dateien zur gemeinschaftlichen Ablage dürfen dort niedergelegt werden.

Nun wollte ich gerne wissen wie ich gewährleisten kann dass immer nur ein Mitarbeiter in diese Datei schreiben kann, da ja ein gleichzeitiger Zugriff zu Verlusten führt.

Ich hatte mir überlegt das bei Click auf Speichern ein wert in der xml datei abgefragt wird.
- Falls dieser "0" dann überschreibe diesen in "1".
- Dann speicher die Daten...
- Nachdem Speichervorgang wird der Wert wieder auf "0" gesetzt.

> Wenn andere versuchen zu schreiben, prüfen diese den wert auf "0". Falls dieser jedoch "1" ist wird ein timer gestartet, ca. 1 sekunde im loop oder ähnlich. erst wenn der wert wieder auf "0" ist wird der Datensatz des anderen Mitarbeiter gespeichert.

> Einziges Problem daran was ich mir durchgespielt habe ist wenn ein System, Client oder Server unerwartet beendet worden sind / heruntergefahren worden sind und nicht mehr den Schreibvorgang "erlauben".

ich hoffe ihr konntet mir folgen... oder habt sogar bessere Ideen für diese Umsetzung.
(Falls es Datenbanksysteme gibt die nicht ständig laufen müssen und die ohne Installation lauffähig sind und ihr noch davon Kenntnis habt dann würde ich mich auch freuen wenn ihr mir diese mitteilt.)

VG

Moin!

Um es kurz zu machen: wenn du nicht über ausreichend Rechte verfügst (ob selbst oder per Delegation - du musst einen DB-Server ja nicht selbst im Zugriff haben), dann wird sich dein Projekt nie "sauber" umsetzen lassen. Nebenbei: wenn sowas in deiner Umgebung nicht "erwünscht" ist, ist es eh fraglich, wie weit es überhaupt Sinn macht, gegen die "SysBetreuer" zu arbeiten... (Es wird ja sicher einen Grund geben, warum das so ist, wie es ist. Und noch mehr nebenbei: ganz konkret bei uns im Netz ist es nicht nur unerwünscht, sondern sogar strikt untersagt Software zu nutzen, die nicht von der IT freigegeben ist! Das kann (arbeits-)rechtliche Aspekte/Konsequenzen haben! Bitte auch mal drüber nachdenken...)

Zurück zum Thema: Haben die Rechner alle Internetzugriff? Dann leg deine DB halt auf einen Server im Internet (wenn es keine großen Datenmengen zu transportieren gibt - die könnte man allerdings auf Share-Basis notfalls lokal bewegen), den hast du dann unter Kontrolle.

Geht auch das nicht, bleibt als letzter Strohhalm: unterstützt das Netzwerkprotokoll des Shares (CIFS?) File-Locking? Dann öffne die Datei mit exklusiven (Schreib-)Rechten, so kann immer nur einer Schreiben, bis der Lock wieder frei ist.

Der Ansatz mit einem selbstverwalteten Semaphor (ob als weitere Datei, Inhalt einer Datei, Node eines XML, *) wird letztlich immer in irgendeiner Art von Chaos enden, so dass ich dir dringend davon abrate, da überhaupt weiter Zeit rein zu investieren, wie man das irgendwie gefrickelt lösen könnte... ehrlich, das wird nix.

cu
Narses

Zum Thema "Sinn"... ich arbeite nicht gegen SysBetreuer, aber der Rattenschwanz bis etwas umgesetzt ist dauert einfach zu lange... dann gehts weiter mit externen Firmen usw.
Manche sehen halt einfach nicht was und wie man optimieren kann, weil einfach gewisse Zusammenhänge und Möglichkeiten nicht erkannt werden.
Dennoch danke für den Hinweis.

Wenn es doch einfach umzusetzen ist dann hätte ich dies halt gemacht. Ist doch eine lobenswerte Einstellung denke ich mal

Internzugriff besteht; jedoch möchte ich keine Dateien ins Netz stellen (Datenschutz).
Eine gemeinsame Netzwerkablage (Share) haben wir; gibt es hierfür direkt DB-Lösungen?

Ob CIFS oder File-Locking aktiviert werden kann weiß ich nicht. Ich gehe einfach mal von einem "nein" aus.

Hast du den auch Beispiele davon das du mir vom Semaphor abraten kannst? (Ich bin so euphorisch das Projekt umzusetzen(!), nur möchte ich auch ungern ein Projekt beginnen ohne zu wissen ob dies wirklich nicht so funktioniert)

Vielen Dank für dein Erfahrungsbericht! Freut mich!

VG

Moin!

whitef hat folgendes geschrieben :

Internzugriff besteht; jedoch möchte ich keine Dateien ins Netz stellen (Datenschutz).

Verschlüssel sie halt.

whitef hat folgendes geschrieben :

Eine gemeinsame Netzwerkablage (Share) haben wir; gibt es hierfür direkt DB-Lösungen?

Sicher gibt es Desktop-Datenbanken, die auf File-Basis arbeiten (um ein totel Pferd zu reiten: die BDE z.B., gibt natürlich auch noch andere, Sybase z.B.). Aber das löst dein Problem nicht: du willst sauberen Mehrbenutzerzugriff/Interlocking und nicht Daten organisieren. Sobald Mehrbenutzerfähigkeit ins Spiel kommt, wirst du langfristig nicht ohne eine Serverinstanz (die für alle Benutzer atomisch ist) glücklich werden. Da führt kein Weg drum rum. (Warum das so ist? Das ist eine Varietät des Turing-Problems, man kann beweisen, dass das nicht lösbar ist; umgangssprachliche Analogie: ein toter Mensch kann dir nicht sagen, dass er tot ist... )

whitef hat folgendes geschrieben :

Ob CIFS oder File-Locking aktiviert werden kann weiß ich nicht. Ich gehe einfach mal von einem "nein" aus.

Hm, ich frag mal so: weißt du, was CIFS und was Filelocking ist?

whitef hat folgendes geschrieben :

Hast du den auch Beispiele davon das du mir vom Semaphor abraten kannst?

Den simpelsten Fall hast du doch schon selbst genannt: wenn ein Client, der das "Schreibrecht" hält, abstürzt, kann er es nicht mehr freigeben (der Tote, der antworten soll... ). Turing hat uns gezeigt, dass man hier nicht ohne eine aussenstehende Instanz (hier: der Server) auskommt (sei es ein RDBMS oder CIFS-File-Locking). Das kann man in beliebig viele Versionen und mit beliebiger Komplexität abwandeln...

Klar kriegt man sowas mit einem manuellen Eingriff immer wieder schnell an´s laufen (wenn es sowas einfaches wie der Client-Absturz ist und du grade greifbar bist - dann bist du diese "aussenstehende Instanz" ). Aber was ist, wenn du mal nicht da bist oder du eine neue Version des "Problems" erstmal selbst (ggfs. lange) suchen musst? Bis du rausgefunden hast, was und wie das passiert ist, da kann schonmal reichlich Zeit in´s Land gehen. Von den technischen Problemen beim Debugging in Multiuser-Umgebungen mal ganz zu schweigen... Meine Erfahrung sagt mir: du wirst mit so einem Ansatz letztlich mehr Zeit damit verbringen, diese technischen Probleme (ich nenn sie jetzt mal so) zu beheben, umgehen, vermeiden, workarounden, patchen, manuell korrigieren, etc.pp, als mit dem fachlichen Teil der Anwendung.

Ich bremse deine Euphorie wirklich nur ungerne, aber es bleibt bei meinem Rat: mach das mit einem Server oder lass es lieber, gibt nur Ärger.

cu
Narses

CIFS / Filelocking: wenn ich ehrlich bin nein. Wie könnte ich testen ob der server dies kann? wie könnte man damit weiterverfahen?

Letzte Möglichkeit wäre vlt. eine kleine Einspielung einer Anwendung auf dem Server. Aber in wie weit so etwas dort läuft mit Diensten usw. weiß auch nicht, da unsere SysB auch nicht den kompletten Zugriff haben

Moin!

whitef hat folgendes geschrieben :

CIFS / Filelocking: wenn ich ehrlich bin nein. Wie könnte ich testen ob der server dies kann? wie könnte man damit weiterverfahen?

Such mal in der Delphi-Hilfe nach TFileStream und nach fmShareDenyWrite, damit kommst du weiter. CIFS kannst du Googlen.

Allerdings wirst du dann mit einer XML-Komponente, die den IO-Layer nicht rausreicht, kaum glücklich werden, weil du das beim Filelocking-Ansatz selbst regeln musst. Die Komponente wird sehr wahrscheinlich davon ausgehen, dass ihr die Datei alleine gehört. Du musst aber nach der Serialisierung eingreifen und den Lock passend behandeln. Ob deine Komponente das kann oder nicht, weiß ich nicht, ich kenne sie nicht.

whitef hat folgendes geschrieben :

Letzte Möglichkeit wäre vlt. eine kleine Einspielung einer Anwendung auf dem Server. Aber in wie weit so etwas dort läuft mit Diensten usw. weiß auch nicht, da unsere SysB auch nicht den kompletten Zugriff haben

Was sind denn das für Typen... Dann vergiss lieber gleich diesen Ansatz.

cu
Narses

Hi,
Danke für den Ansatz.
Habe mal ein Testtool gebastelt um eine Datei mit filelock in ein Stream zu laden (iVm fmShareDenyWrite).
Auf dem beimpf klappt auch diese "Prioritäten dateiöffnung".
Mal schauen wie es im Firmennetzwerk ausschaut (morgen) - über einen Share.
Sollte aber gleich sein denke ich mal.

Im Prinzip ist dies ja nur ein semaphor vom Betriebssystem speziell auf die eine Datei, oder?

Moin!

whitef hat folgendes geschrieben :

Im Prinzip ist dies ja nur ein semaphor vom Betriebssystem speziell auf die eine Datei, oder?

Ja, genau das ist es (und da ist auch wieder die "aussenstehende Instanz", dein Server ).

Du kannst mit dem File-Locking nun auf OS-Ebene ausschließen, dass die Datei beim Schreiben beschädigt wird. Du musst aber auch damit klar kommen: die Clients haben ja so gesehen eine lokale Kopie der gesamten XML-Datei vorliegen (praktisch wie in einem Cache). Beispiel:

• Client A lädt die XML in die Kompo-A
  
• Client B lädt die XML in seine Kompo-B
  
• Client A schreibt eine Änderung aus Kompo-A zurück in die Datei
  
• Client B möchte auch eine Änderung aus seiner Kompo-B schreiben... Bumm! B weiß nichts von der Änderung durch A...

Viel Erfolg!

cu
Narses

Hallo

Das Problem wird oft mit einem Update Timestamp entschärft. Allerdings ist das für den zweiten nicht gerade die praktischste art...

Bevor man die Daten speichert liest man sie nochmals. Ist der Update Timestamp noch der selbe wie beim ersten lesen kann die Datei gespeichert werden. Ist der Update Timestamp nicht mehr der selbe wie bei ersten lesen wurde inzwischen von einem anderen User eine Änderung gemacht. Das speichern der neuen Änderungen wird verworfen. Der User den dies Trifft wird wohl nicht gerade Freude haben Besonders bei umfangreichen Mutationen... Daher sollte er immer noch die Möglichkeit haben diese Datei lokal abzuspeichern da er wohl seine Änderungen nochmals machen muss.

Gruss

Bole

Edit: Mein 100 Beitrag