synchronisationsproblem

[php_rookie]

hi!

versuch mich grad an einem wiki und stehe vor folgendem problem: wenn ein benutzer eine seite ändern will und ein zweiter benutzer die selbe seite parallel dazu bereits editiert, dann soll der benutzer welcher später auf "speichern" drückt eine fehlermeldung zurückbekommen.

folgendes szenario:

benutzer 1: seite editieren
benutzer 2: seite editieren
benutzer 2: seite speichern
benutzer 1: seite speichern

sollte bei benutzer 1 also in einer fehlermeldung resultieren, dass die daten während des editiervorgangs editiert wurden, er die änderungen kopieren und mit der neuen version vergleichen soll.

man könnte nun anhand der versionsnummer des dokumentes oder anhand des änderungsdatums überprüfen, ob zwischen dem aufruf des quelltextes und dem speichern eine neue version eingefügt wurde.

hierzu sind jedoch zumindest 2 sql-queries nötig: eines zum abfragen der version/speicherzeit und eines zum einfügen der überarbeiteten version. zwischen dieses statements *könnte* ein benutzer jedoch eine neue version einfügen, so unwahrscheinlich es auch ist.

irgendwelche ideen wie man das sicher synchronisieren kann?

[marc75]

wie wäre es denn so:

wenn Nutzer 1 das Dokument aufruft, speerst du die Editfunktion für alle anderen und gibst diese erst nach dem Speichern oder einer Zeit X wieder frei für das Dok.

Wenn jetzt Nutzer 2 das Dokument aufruft, sollte er gleich sehen das er es nicht editieren kann.

[php_rookie]

genau den weg möchte ich nicht gehen. wenn benutzer 2 eine schnelle änderung vornehmen möchte (rechtschreibfehler, etc.) benutzer 1 jedoch eine umfangreichere änderung plant oder einfach kurz was essen geht, das browserfenster geöffnet lässt, nicht auf speichern drückt und somit die editier-funktion nicht wieder freigibt, dann wartet benutzer 2 mitunter ewig...

[asp2php]

du kannst so machen:

- beim Senden des Dokuments zum User gibst du das geänderte Datum mit (oder in die Session speichern, oder ...)
- vor dem Speichern prüfst du ob das geänderte Datum von User mit dem von Dokument identisch ist oder nicht, wenn ja speichern, wenn nein, nicht speichern und Meldung an User mit neuem Inhalt und geänderte Datum. Dann kann er:
++ den neuen Inhalt anschauen und ggf. sein Edit ändern
++ erneut mit seinem Edit speichern

[php_rookie]

vor dem Speichern prüfst du ob das geänderte Datum von User mit dem von Dokument identisch ist oder nicht, wenn ja speichern, wenn nein, nicht speichern und Meldung an User mit neuem Inhalt und geänderte Datum.

das wiederum ist genau das 2-queries-problem, das ich oben angesprochen hatte, d.h. es ist nicht wirklich synchron. oder versteh ich das jetzt falsch?

[asp2php]

sind die Daten in einer Datenbank, etwa MySQL? wenn ja, dann vor der 1. Abfrage ein lock table absetzen und nach dem update ein unlock

[a4u]

Original geschrieben von asp2php
sind die Daten in einer Datenbank, etwa MySQL? wenn ja, dann vor der 1. Abfrage ein lock table absetzen und nach dem update ein unlock

Und stirbt der Benutzer zwischenzeitlich, muss MySQL sich irgendwann um die gesperrte Tabelle kümmern ...

An dieser Stelle empfiehlt sich tatsächlich, entweder eine crc32 / md5-Information per hidden-field mitzusenden oder, da es sich um ein Wiki handelt, Versionsdaten mitzuspeichern und das Problem des gleichzeitigen Schreibens zu ignorieren.

Somit kann die alte (neue) Version einfach wiederhergestellt werden, um dort dann abschließend den Rechtschreibfehler auszubügeln.

[php_rookie]

@ asp2php: ja, die daten liegen in einer mysql datenbank. ein lock table sperrt benutzer 2 aus und das ist von mir nicht beabsichtigt. die speicherrechte soll derjenige user bekommen, der zuerst auf speichern drückt.

alle anderen die immer noch an der seite arbeiten sollen eine fehlermeldung retour bekommen. diese user von vorne herein auszuschließen und nur einen einzigen benutzer editieren zu lassen ist nicht in meinem sinne (klassisches mutal exlusion beispiel mit semaphoren).


@ a4u:

An dieser Stelle empfiehlt sich tatsächlich [...] das Problem des gleichzeitigen Schreibens zu ignorieren.

die methode versionsnummern zu protokollieren (in der session, da formulardaten manipulierbar sind) ist mir auch schon vorgeschwebt (siehe einleitendes posting).

das problem ist, dass ich vor dem speichern auslesen muss, ob die höchste versionsnummer der aktuellen seite mit der in der session gespeicherten übereinstimmt --> erstes query. stimmen die versionsnummern überein kann eine neue version in die datenbank gelegt werden --> zweites query.

stimmen sie nicht überen, d.h. die höchste versionsnummer ist größer als die nummer in der session, dann erhält man besagte fehlermeldung retour.

so hab ich es im moment. das klappt auch ganz gut ist aber IMHO nicht ganz richtig so. ist das die einzige möglichkeit sowas zu realisieren?

[a4u]

Ersatzweise fällt mir nur ein Query der Form
UPDATE ... WHERE timestamp='$mein_als_hidden_field_gespeicherter_timestamp'
ein.

Dann kannst du per mysql_affected_rows () herausfinden, ob der Schreibvorgang klappte - wenn nein, brauchst du einen zweiten Query (oder eine einfache Fehlermeldung, aber das werden dir die Autoren übel nehmen ...)

Vorteile: Nur ein SQL-Query nötig; 99.9%iger Schutz vor Überschreiben von zwischenzeitlichen Änderungen

Nachteile: Theoretisch leicht manipulierbar; vorheriger Inhalt wird überschrieben; und wahrscheinlich noch eins / zwei mehr

[marc75]

ich persöhnlich würde es recht doof finden, wenn ich einen Text aufwendig bearbeite und erst nach dem Absenden eine Mitteilung erhalte das der alte Text bereits geändert wurde, in diesem Augenblick weiss ich ja dann nicht mal was es bereits geändert wurde.

aber naja...muss jeder selbst wissen....

[php_rookie]

vorab mal ein herzliches dankeschön für eure beiträge und denkanstöße!

@ a4u:

Ersatzweise fällt mir nur ein Query der Form
UPDATE ... WHERE timestamp='$mein_als_hidden_field_gespeicherter_timestamp'
ein.

wäre auch ein ansatz, allerdings ist ein update von bestehenden datensätzen nicht möglich, da jede änderung als neuer datensatz in die tabelle eingefügt werden soll. die versionskontrolle soll über die fortlaufende id erfolgen, da der timestamp ja nicht zwingend eindeutig sein muss (2 beiträge werden unmittelbar nacheinander abgeschickt und eingereiht --> beide haben den selben timestamp in sekunden).

@marc:

in diesem Augenblick weiss ich ja dann nicht mal was es bereits geändert wurde.

doch, das weiß man. ich hab auch eine versions-history implementiert in der sämtliche änderungen zwischen den einzelnen versionen sichtbar werden.

ich sehs von der seite (ein beispiel): wenn ich einen kurzen druckauftrag an einen netzwerkdrucker senden will - z.b. nur eine einzige seite - und ich dann erst warten muss bis ein umfangreicherer druckauftrag - z.b. 500 seiten - erledigt ist, dann würde mich das nerven.

oder: wenn ich mir an einer moviethek einen film ausleihen möchte und genau weiß welchen film ich haben will und mein vordermann sich einfach nicht entscheiden kann, dann nervt mich das auch.

genauso ist es bei wiki-seiten: ich seh einen rechtschreibfehler oder möchte nur einen kurzen satz hinzufügen, während ein anderer die seite komplett neu gestalten möchte, dann muss ich warten bis er damit fertig ist und kann die änderungen erst dann vornehmen.

meine seite ist nicht so groß, dass die benutzer längere zeit warten würden bis sie ihre änderungen vornehmen können. theoretisch könnten während der zeit einer größeren änderung so auch mehrere kleinere änderungen vorgenommen werden.