überschreiben von Änderungen vermeiden

[Andreas Korthaus]

Hallo!

Ich habe eine Oberfläche gebastelt, mit der ein Benutzer Daten aus 3 Tabellen bearbeiten kann. Das funktioniert auch alles schön und gut, nur überlege ich jetzt, was denn passiert wenn 2 Leute gleichzeitig die Daten ändern, und so der eine die Änderungen des anderen überschreibt.
Da es ein paar mehr Daten sind habe ich das Änderungs-Formular auf 3 Seiten verteilt, am Anfang lese ich die Daten in die Session ein, dann werden die Daten in der Session geändert und am Ende wenn man "speichern" klickt werden die Daten aus der Session in die DB geschreiben. Das hatte ich mir so überlegt um
1. hier ca. 80-90% der DB-Zugriffe zu sparen, und
2. Änderungen rückgängig machen zu können

Aber was wenn jetzt 2 Benutzer dieselben Daten editieren wollen? Das darf nicht sein, also muss ich mir eine Art Locking-Mechanismus überlegen. Ein SQL-LOCK macht keinen Sinn da er nur für die Laufzeit des Scriptes auf dem Server Bestand hat. Alternativ könnte ich auch ein Flag in die Tabellen schreiben und das ggfs. verändern wenn die Daten gerade bearbeitet werrden, andere Benutzer erhalten dann eien Fehlermeldung. Nur hat das auch wieder einen Haken, denn wenn ein Benutzer jetzt die Daten editieren will, dann aber nichts mehr macht sind die Daten auf ewig gesperrt, also muss ich noch einen Timestamp hinzufügen, und sagen wir mal nach 10 Minuten Inaktivität das Flag zurücksetzen. Nur wie gesagt sind es ein paar mehr Daten und das Ändern könnte durchaus mal etwas dauern.

Irgendwie bin ich nicht so ganz glücklich mit dieser Version, habt Ihr vielleicht eine bessere Idee wie man sowas machen könnte?

Viele Grüße
Andreas

[Lude]

Hi,

Ich habe eine Oberfläche gebastelt, mit der ein Benutzer Daten aus 3 Tabellen bearbeiten kann. Das funktioniert auch alles schön und gut, nur überlege ich jetzt, was denn passiert wenn 2 Leute gleichzeitig die Daten ändern, und so der eine die Änderungen des anderen überschreibt.

das wuerde ich einen Konflikt nennen. Das kann nicht ausgeschlossen werden, es sei denn Du unterstuetzt das "Aus-Checken" von Datensaetzen (Datenmengen).

Aber was wenn jetzt 2 Benutzer dieselben Daten editieren wollen? Das darf nicht sein, also muss ich mir eine Art Locking-Mechanismus überlegen.

Du keonntest ein "Aus-Checken" so implementieren, dass vor dem Zurueckschreiben geprueft wird, ob der Datensatz nach dem Lesen in einer anderen Sitzung zwischenzeitlich upgedated worden ist. Da helfen traditionell Datenfelder vom Typ 'datetime', oder auch ein Revisionszaehler vom Typ 'int'.

Nur hat das auch wieder einen Haken, denn wenn ein Benutzer jetzt die Daten editieren will, dann aber nichts mehr macht sind die Daten auf ewig gesperrt, also muss ich noch einen Timestamp hinzufügen, und sagen wir mal nach 10 Minuten Inaktivität das Flag zurücksetzen.

Wegen der Verbindungslosigkeit von http benoetigst Du einen Sitzungstimeout.

Nur wie gesagt sind es ein paar mehr Daten und das Ändern könnte durchaus mal etwas dauern.

Es gibt nichts besseres, drum sei gluecklich.   ;-)

Gruss,
Lude

[Michael Schröpl]

Hallo Andreas,

Ich habe eine Oberfläche gebastelt, mit der ein Benutzer Daten aus 3 Tabellen bearbeiten kann. Das funktioniert auch alles schön und gut, nur überlege ich jetzt, was denn passiert wenn 2 Leute gleichzeitig die Daten ändern, und so der eine die Änderungen des anderen überschreibt.

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.

Eine Transaktion ist nur das Ganzes durchführbar, sie umfaßt beliebig viele SQL-Statements (auf beliebig vielen Tabellen) und endet mit "commit" oder "rollback".
Unterstützt Dein RDBMS dieses Konzept?

Aber was wenn jetzt 2 Benutzer dieselben Daten editieren wollen? Das darf nicht sein, also muss ich mir eine Art Locking-Mechanismus überlegen.

Generationen von Datenbank-Herstellerfirmen beschäftigen sich mit diesem Problem seit mehreren Jahrzehnten.
Dein Skript muß mir der Situation leben können, daß eine Transaktion auch scheitern kann - das ist alles. (Ob Du in diesem Falle automatisch einen retry machst oder eine Fehlermeldung ausgibst, das ist Deine Design-Entscheidung.)

Viele Grüße
      Michael

[Lude]

Hallo, Michael,

schoen, dass Du mal wieder da bist.

Ich habe eine Oberfläche gebastelt, mit der ein Benutzer Daten aus 3 Tabellen bearbeiten kann. Das funktioniert auch alles schön und gut, nur überlege ich jetzt, was denn passiert wenn 2 Leute gleichzeitig die Daten ändern, und so der eine die Änderungen des anderen überschreibt.

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.

ich kenne Transaktionen so, dass man mithilfe dieser sicherstellt, dass mehrere Aktionen entweder zusammen ausgefuehrt werden oder gar nicht. Ausserdem sollten Transaktionen immer sehr schnell geschlossen werden, da diese sehr ressourcenfressend sind.

Wenn man aber auf Datensaetze zugreift, auf die auch andere zugreifen koennen, so wuerde ich eher mit folgenden Konzepten rechnen:

• Optimismus, d.h. wenn ein Datensatz mehrfach fuer Editierzwecke gelesen wird, gestattet man beim Zurueckschreiben einfach das jeweils alles ueberschrieben wird.
• Pessimismus, d.h. ein Locking verhindert, dass ein ausgecheckter Datensatz (unter http ist das Aus-Checken rein "logischer" Art) ein zweites mal fuer Editierzwecke geladen werden kann
• ein Zwischending - der Datensatz wird gelesen und nur dann zurueckgeschrieben, wenn der Shadow des urspruenglich gelesenen Datensatztes mit dem aktuellen Inhalt uebereinstimmt

Ausserdem denkbar noch eine Revisionierung von Aenderungen mit spaeterer Konfliktaufloesung, was aber meist wegen grossen Aufwands nicht in Betracht gezogen wird.

Viele Gruesse,
Lude

[Michael Schröpl]

Hi Lude,

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.
ich kenne Transaktionen so, dass man mithilfe dieser sicherstellt, dass mehrere Aktionen entweder zusammen ausgefuehrt werden oder gar nicht.

nicht nur das. Insbesondere gewährt Dir eine Transaktion eben _auch_ eine konsistente Sicht auf die entsprechenden Tabellen, welche nicht durch andere Prozesse verändert wird.

Ausserdem sollten Transaktionen immer sehr schnell geschlossen werden, da diese sehr ressourcenfressend sind.

Richtig. (Rollback-Segmente etc. - gerade das Bereitstellen der konsistenten Datensicht kann bei parallelen Zugriffen auf diese Tabelle teuer werden.)

• Optimismus, d.h. wenn ein Datensatz mehrfach fuer Editierzwecke gelesen wird, gestattet man beim Zurueckschreiben einfach das jeweils alles ueberschrieben wird.

Eine Transaktion kann ein UPDATE-Statement mit einer WHERE-Klausel enthalten, welche sicherstellen soll, daß eben genau niemand vorher diesen Inhalt verändert.
Würdest Du 'zwischendurch' eine weitere Änderung des Inhaltes erlauben, dann würde dies die Semantik des SQL-Statements ändern (stell Dir vor, das Statement liest einen Zähler aus und erhöht ihn um 1 - in Deinem Modell würde die Zwischendurch-Änderung verloren gehen).

• Pessimismus, d.h. ein Locking verhindert, dass ein ausgecheckter Datensatz (unter http ist das Aus-Checken rein "logischer" Art) ein zweites mal fuer Editierzwecke geladen werden kann

Im Prinzip macht dies das RDMBS auch so, glaube ich. Es merkt sich, daß ein Prozeß eine Transaktion auf einer Tabelle offen hat, markiert die entsprechenden Blöcke und stellt sicher, daß von diesen on the fly eine Kopie hergestellt wird, sobald innerhalb der Transaktion darin Änderungen vorgenommen werden - denn andere, lesende Prozesse müssen zu diesem Zeitpunkt ja noch die vorherige Sicht auf diese Tabelle erhalten.

Erst bei Festschreiben der Transaktion werden die Änderungen aus in die eigentliche Tabelle übertragen, vermute ich - wie das genau implementiert ist, müßte man dem Quelltext des jeweiligen Tabellentreibers (im Falle von mySQL) entnehmen können (wobei die Standard-Tabellentreiber von mySQL gar keine Transaktionen unterstützen, aber z. B. der InnoDB-Treiber schon).

Ich vermute, es ist tatsächlich eine Mischung all Deiner Ideen - ein solcher Locking-Mechanismus ist zumindest erforderlich, um Kollisionen zu erkennen.
Tatsächlich wird es aber möglich sein, daß zwei Prozesse gleichzeitig eine Transaktion auf demselben Abschnitt derselben Tabelle durchführen - und wer zuerst committet, der gewinnt, während der andere seine Transaktion zurückgerollt bekommt und von vorne beginnen muß (das ist der "optimistische" Ansatz - denn so etwas sollte natürlich möglichst selten tatsächlich passieren).

Die Hauptsache ist, daß kein Statement unter falschen Voraussetzungen ausgeführt wird. Eine Garantie für den erfolgreichen Abschluß einer Transaktion gibt es nicht - aber wenn eine Transaktion tatsächlich festgeschrieben wurde, dann wurde sie auch unter den gewünschten Voraussetzungen ausgeführt. Wenn nicht, dann muß die Anwendung es eben noch einmal versuchen - oder was auch immer.

Ausserdem denkbar noch eine Revisionierung von Aenderungen mit spaeterer Konfliktaufloesung, was aber meist wegen grossen Aufwands nicht in Betracht gezogen wird.

Um eine Transaktion zurückzurollen, kann man entweder zuerst eine Kopie ziehen und diese später festschreiben, oder sofort festschreiben und Revisionsinformationen speichern - eines von beidem ist unvermeidlich, weil für parallele Transaktionen eine parallele Buchführung erforderlich ist.

Was von beidem wie gut funktioniert, hängt von der zu erwartenden Kollisionsrate ab.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.

Eine Transaktion ist nur das Ganzes durchführbar, sie umfaßt beliebig viele SQL-Statements (auf beliebig vielen Tabellen) und endet mit "commit" oder "rollback".
Unterstützt Dein RDBMS dieses Konzept?

Ja, aber das Problem ist die Client-Server Architektur. Meines Wissens ist es nicht möglich mit PHP auf dem Server eine Transaktion zu starten, den Thread zu beenden, und bei einem Request 10 Minuten später diese Transaktion wieder aufzunehmen und zu beenden. Wenn das alles innerhalb eines Scripte wäre hätte ich auch kein Problem, nur liegt zw. dem Start und dem Ende der Transaktion das Ausfüllen von 3 HTML-Formularen und dem entsprechend der HTTP Verkehr vor und nach jedem Ausfüllen eines Formulares. Solange darf das nichts passieren. Soweit ich weiß wird die Transaktion automaisch beendet, sobald das Script welches die Transaktions gestartet hat beendet ist. Oder gibts da doch eine Möglichkeit? Das wäre natürlich genial!

Aber was wenn jetzt 2 Benutzer dieselben Daten editieren wollen? Das darf nicht sein, also muss ich mir eine Art Locking-Mechanismus überlegen.

Generationen von Datenbank-Herstellerfirmen beschäftigen sich mit diesem Problem seit mehreren Jahrzehnten.

Wer sagt dass ich es nicht mal eben besser machen kann?
*Scherz* ;-)

Dein Skript muß mir der Situation leben können, daß eine Transaktion auch scheitern kann - das ist alles. (Ob Du in diesem Falle automatisch einen retry machst oder eine Fehlermeldung ausgibst, das ist Deine Design-Entscheidung.)

Ja, und das geht wohl nur über einen Timeout. Im Prinzip bilde ich ja eine Transaktion nach wenn ich den Datensatz mit einem Flag sperre, und da HTTP Zustandslos ist brauche ich halt mal wieder diesen Timeout. Oder meinst DU dasgeht auch anders?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.
das Problem ist die Client-Server Architektur. Meines Wissens ist es nicht möglich mit PHP auf dem Server eine Transaktion zu starten, den Thread zu beenden, und bei einem Request 10 Minuten später diese Transaktion wieder aufzunehmen und zu beenden. Wenn das alles innerhalb eines Scripte wäre hätte ich auch kein Problem, nur liegt zw. dem Start und dem Ende der Transaktion das Ausfüllen von 3 HTML-Formularen und dem entsprechend der HTTP Verkehr vor und nach jedem Ausfüllen eines Formulares. Solange darf das nichts passieren.

Genau. Du solltest alle Daten der Transaktion inkrementell aufsammeln (Session!) und die eigentliche Änderung in der Datenbank erst dann starten, wenn Du alles in einem Rutsch durchführen kannst. Dann greift das Transaktionskonzept, und Dein Problem ist gelöst.

Und Du mußt in diesem Moment immer noch darauf achten, daß Dir inzwischen die Grundlagen für diese Transaktion entzogen worden sein können, weil jemand anderes weniger als 10 Minuten brauchte, um eine Änderung einzugeben. Dies kannst Du ggf. durch entsprechende WHERE-Klauseln in Deinen UPDATE-Statements sicherstellen (aus Effizienzgründen könnte ein Timestamp der letzten Änderung pro Datensatz helfen).

Ja, und das geht wohl nur über einen Timeout. Im Prinzip bilde ich ja eine Transaktion nach wenn ich den Datensatz mit einem Flag sperre, und da HTTP Zustandslos ist brauche ich halt mal wieder diesen Timeout. Oder meinst DU dasgeht auch anders?

Löse Dich von der Idee, Deine SQL-Statements auf mehrere Skripte zu verteilen - genau hier liegt Dein Problem.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

Genau. Du solltest alle Daten der Transaktion inkrementell aufsammeln (Session!) und die eigentliche Änderung in der Datenbank erst dann starten, wenn Du alles in einem Rutsch durchführen kannst.

Ja, genau so mache ich es bereits. Das Problem liegt wo anders. Wenn jemand einen Datensatz zum bearbeiten aufruft, ab diesem Moment darf das niemand anders mehr machen können, denn sonst hötten 2 Leute dieselben Daten und würde aber evtl. verschiedene Änderungen vornehmen udn sich gegenseitig überschreiben. Also Transaktion, aber was heißt das jetzt genau? Eigentlich ist es einfach. Anwender 1 öffnet die Daten zum bearbeiten, die Daten werden mit einem Flag versehen, so dass niemand anderes mehr drankommt. Jetzt macht Nawender 1 diese und jene Änderung, und speichert am Ende, das Flag wird wieder zurückgesetzt und jeder andere kann jetzt diese Daten bearbeiten. Nur - was ist wenn Anwender 1 die Daten bearbeiten will, daber aber ein Problem auftaucht, er weiß nicht was er in ein Feld schreiben soll, ruft irgendwo an... und ist 2 Stunden beschäftigt bis er endlich weiß was jetz genau da hin soll. Was soll dann passieren? Sollen jetz alle anderen 2 Stunden warten müssen? Und wenn es denn einen Timeout von 15 Minuten gibt - was passiert dann mit den Daten von Anwender 1 die er ja bereits eingegeben hat? Was passiert wenn er nach 2 Stunden, also 1 3/4 Stunden über das Limit kommt und abschickt? Die Daten alle weg?

Dann greift das Transaktionskonzept, und Dein Problem ist gelöst.

Wenn das so einfach wäre...

Und Du mußt in diesem Moment immer noch darauf achten, daß Dir inzwischen die Grundlagen für diese Transaktion entzogen worden sein können, weil jemand anderes weniger als 10 Minuten brauchte, um eine Änderung einzugeben.

Ja, aber das will ich auch nicht. Wenn Anwender 1 Daten eingibt, soll Anwender 2 eine Fehlermeldung erhalten und nicht ebenfalls Daten eingeben können, denn sonst würden beide parallel Daten eingeben, und  einer davon wird das auf jeden Fall um sonst gemacht haben, das ist sehr ärgerlich. Fände ich zumindest.

Löse Dich von der Idee, Deine SQL-Statements auf mehrere Skripte zu verteilen - genau hier liegt Dein Problem.

Das habe ich nie gemacht, ich habe eine Session in die alles reingeschreiben wird, am Ende eien Statusseite wo alle Eingaben kontrolliert werden, und dann einen "Speichern"-Button.

Viele Grüße
Andreas

[Lude]

Hi,

ich hatte versucht Dein Problem zu umreissen und 4 verschiedene Loesungen vorgeschlagen. - Hast Du das nicht gelesen?

Gruss,
Lude

[Michael Schröpl]

Hi Andreas,

Ja, genau so mache ich es bereits. Das Problem liegt wo anders. Wenn jemand einen Datensatz zum bearbeiten aufruft, ab diesem Moment darf das niemand anders mehr machen können,

doch, darf er. Nur muß die bereits begonnene Transaktion zum Zeitpunkt ihres "commit" merken, daß jemand anderes ihr zuvor gekommen ist (beispielsweise über WHERE-Klauseln ihrer UPDATE-Statements). Diese Transaktion wird dann scheitern, und Dein Skript muß mit dieser Situation fertig werden.

Anwender 1 öffnet die Daten zum bearbeiten, die Daten werden mit einem Flag versehen, so dass niemand anderes mehr drankommt.

Das wäre der "pessimistische" Ansatz. Der "optimistische" scheint mir performanter zu sein - je nach Randbedingungen (siehe unten).

Nur - was ist wenn Anwender 1 die Daten bearbeiten will, daber aber ein Problem auftaucht

Dann muß Dein Skript dieses Problem lösen. Vielleicht schickt es den Anwender zurück zum Schritt 1 des Dialogs; vielleicht kann es die transaktionsrelevanten Daten selbst anpassen; vielleicht gibt es eine Meldung aus, daß diese Daten bereits eingegeben wurden. Was davon zutrifft, hängt von Deiner Anwendungslogik ab.

Und Du mußt in diesem Moment immer noch darauf achten, daß Dir inzwischen die Grundlagen für diese Transaktion entzogen worden sein können, weil jemand anderes weniger als 10 Minuten brauchte, um eine Änderung einzugeben.
Ja, aber das will ich auch nicht.

Für die optimale Lösung Deines Problems ist irrelevant, was Du "willst". ;-)

Wenn Anwender 1 Daten eingibt, soll Anwender 2 eine Fehlermeldung erhalten und nicht ebenfalls Daten eingeben können, denn sonst würden beide parallel Daten eingeben, und  einer davon wird das auf jeden Fall um sonst gemacht haben, das ist sehr ärgerlich. Fände ich zumindest.

Wer sagt Dir, daß beide dieselben Daten eingeben? Und wie hoch ist die Wahrscheinlichkeit, daß dieser Fall auftritt? So etwas läßt sich arbeitsmethodisch minimieren, beispielsweise durch Absprachen und Zuständigkeiten - oder durch eine automatische Aufteilung der Eingabedaten.
Entscheidend ist ja nicht, daß es nie Doppeleingaben gibt, sondern daß diese in der Summe nicht teuer werden. Datenverlust fände ich im Vergleich dazu schlimmer.

Wenn allerdings nur genau diese Synchronisation Dein Ziel ist, dann wäre ein triviales Flag in der Tat die einfache Lösung.
Wie bei jeder Synchronisation brauchst Du eine atomare Operation "test and set", um ein Semaphor zuverlässig zu setzen - über eine entsprechende WHERE-Klausel im UPDATE sollte das möglich sein: Wenn mehrere Prozesse versuchen, "UPDATE t_semaphor SET flag=1 WHERE flag=0" (oder wie das in dem entsprechenden SQL-Dialekt gerade heißen mag ...) auszuführen, dann wird anschließend sicherlich das Flag auf 1 stehen, aber die Prozesse sollten unterschiedliche Returncodes über die Ausführung ihrer Statements erhalten.

Löse Dich von der Idee, Deine SQL-Statements auf mehrere Skripte zu verteilen - genau hier liegt Dein Problem.
Das habe ich nie gemacht, ich habe eine Session in die alles reingeschreiben wird, am Ende eien Statusseite wo alle Eingaben kontrolliert werden, und dann einen "Speichern"-Button.

Auch das Setzen Deines Flags ist ein Teil des transaktionsrelevanten Codes: In diesem Moment öffnest Du - semantisch betrachtet - die Transaktion. Und genau das ist Dein Problem: Ab diesem Moment kann viel Zeit vergehen, bis die Transaktion geschlossen wird.

Wenn es Dir wirklich nur darum geht, Doppeleingaben zu verhindern, dann ist ein zuverlässiges Record-Locking wahrscheinlich die beste Lösung - dann jedoch sind alle Deine Fragen, was in bestimmten Problemfällen passiert, separat zu behandeln ... Du kannst innerhalb des Semaphors beispielsweise eine Session-ID speichern, welche bei nachfolgenden Zugriffen auf das gesperrte Objekt ebenfalls abgefragt wird, so daß ein Prozeß erkennen kann, daß ihm sein Semaphor von der Ablaufsteuerung gewaltsam entzogen wurde (timeout etc.).

Viele Grüße
      Michael

[Lude]

Hallo, Michael,

Wenn es Dir wirklich nur darum geht, Doppeleingaben zu verhindern, dann ist ein zuverlässiges Record-Locking wahrscheinlich die beste Lösung - dann jedoch sind alle Deine Fragen, was in bestimmten Problemfällen passiert, separat zu behandeln ... Du kannst innerhalb des Semaphors beispielsweise eine Session-ID speichern, welche bei nachfolgenden Zugriffen auf das gesperrte Objekt ebenfalls abgefragt wird, so daß ein Prozeß erkennen kann, daß ihm sein Semaphor von der Ablaufsteuerung gewaltsam entzogen wurde (timeout etc.).

Du haeltst hier Vortraege ueber Transaktionen und deren Implikationen, waehrend der Mann doch einfach nur sicherstellen moechte, dass Aenderungen an bestimmten Datensaetzen auf eine Art und Weise geschehen, die "beabsichtigt" ist. Also, wenn wir spekulieren, dann vielleicht eine "pessimistische" Herangehensweise.

Meine Anregungen werden ignoriert, moeglicherweise sogar aus Gruenden, die sachfremd sind. - Koenntest Du da nicht etwas aufklaerend wirken?

Gruss,
Lude

[Andreas Korthaus]

Hallo!

Wenn es Dir wirklich nur darum geht, Doppeleingaben zu verhindern, dann ist ein zuverlässiges Record-Locking wahrscheinlich die beste Lösung - dann jedoch sind alle Deine Fragen, was in bestimmten Problemfällen passiert, separat zu behandeln ... Du kannst innerhalb des Semaphors beispielsweise eine Session-ID speichern, welche bei nachfolgenden Zugriffen auf das gesperrte Objekt ebenfalls abgefragt wird, so daß ein Prozeß erkennen kann, daß ihm sein Semaphor von der Ablaufsteuerung gewaltsam entzogen wurde (timeout etc.).

Genau das ist es. Ich hatte gehofft es gäbe dann doch noch eine schönere Lösung aber anscheinend nicht. Doppeleingaben darf es nicht geben. Z.B. bei einer Artikel-Tabelle, wenn ich da was dran ändere, darf Gustav das nicht überschreiben. ich könnte zwar prüfen welche Felder aktualisiert werden und Gustav darf dann halt nur die andeen Felder bearbeiten, aber as ist auch nicht wirklich schön, zumal sich das erst am Ende feststellen lässt udn Gustav so viewlleicht schon eine andere Angabe für dasselbe Feld gemacht hat, aber noch nicht gespeichert.

Du haeltst hier Vortraege ueber Transaktionen und deren Implikationen, waehrend der Mann doch einfach nur sicherstellen moechte, dass Aenderungen an bestimmten Datensaetzen auf eine Art und Weise geschehen, die "beabsichtigt" ist. Also, wenn wir spekulieren, dann vielleicht eine "pessimistische" Herangehensweise.

Es ist ja auch eine Transaktion. Nur kann ich eben keien Transaktion auf RDBMS-Level verwenden. Da wünschte ich mir jetzt wirder einen Applikationsserver mit Java, da gibt es für sowas glaube ich schon fertige Lösungen. Jetzt ernet ich halt die Früchte dere Entscheidung für PHP, naja, aber so scher ist es ja nicht, Du hattest schon Recht am Anfang. Ich werde bei dem Datensatz ein Flag einfügen, dazu einen Timestamp und den Username. Dann weiß ich immer ob meine Transaktion abgebrochen wurde. Nur weiß ich noch nicht genau wie ich das in die Anwendung einbaue. Was soll passieren wenn der Timeout abgelaufen ist? Soll ich erst bei eine neuen ZUgriff durch eine andere Person nach 20 Minuten die Transaktion einfach abbrechen, oder kann ich davor irgendwie den 1. Anwender kontaktieren dass der entscheiden kann ob verworfen oder gespeichert wird? Ich könnte ja sogar in die Session gucken ob der schon Änderungen gemacht hat, das wäre kein Problem.
Nur wernn ich jetzt sowas mache - dann muss der 2. Anwender erst warten bis der erste reagiert hat, das ist ja auch irgendwie blöd.
Oder ich lade nach dem Timeout ein Javascript welches ein Confirm-Fenster öffent in dem gefragt wird ob die Daten gesoeichert werden sollen und ein neue "Transaktion" gestartet werden soll...

Was meint Ihr?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Lude,

Du haeltst hier Vortraege ueber Transaktionen und deren Implikationen, waehrend der Mann doch einfach nur sicherstellen moechte, dass Aenderungen an bestimmten Datensaetzen auf eine Art und Weise geschehen, die "beabsichtigt" ist.

"der Mann" ist mir nicht völlig unbekannt. Befrage das Archiv diesbezüglich.

Viele Grüße
      Michael