doppelte Bearbeiung von Datensätzen vermeiden?

Hallo,

ich habe eine DB, an der mehrere Mitarbeiter gleichzeitig Daten
einpflegen oder ändern.

Um Überschneidungen auszuschließen soll ein Datensatz, während
er bearbeitet wird von den anderen Mitarbeitern nicht editiert oder
gelöscht werden können.

Ich dachte mir das so, dass immer, wenn ein Datensatz bearbeitet wird,
die jeweilige ID des Datensatzes in eine Tabelle geschrieben wird,
über die man dann abprüfen kann, welche Datensätze gerade in Bearbeitung
sind. Ist die Bearbeitung abgeschlossen, wird die ID wieder aus der
Tabelle gelöscht.

Aber was mache ich, wenn die Bearbeitung abgebrochen wird? Der
Rechner abstürzt oder andere Ereignisse, die verhindern, dass
die ID aus der "EDIT-Tabelle" entfernt wird?
Ich dachte dabei an einen Timestamp, anhand dessen "überfällige" IDs
automatisch wieder zur Bearbeitung freigegeben werden?

Aber wie lange kommt man dann nicht an den Datensatz heran? Oder ist
diese Überlegung nicht so günstig?

Danke

Mark Knochen


--
www.zeitfuerwahrheit.de

************************************************************ ************
*
Beim großen Manual, ich habe gesprochen! *
*
************************************************************ ************
*
"Ich habe Dinge gesehen, die ihr Menschen niemals glauben würdet. *
Gigantische Schiffe, die brannten, draußen vor der Schulter des Orion. *
Und ich habe C-Beams gesehen, glitzernd im Dunkel, *
nahe dem Thannhäuser-Tor. *
All diese Momente werden verloren sein... in der Zeit, *
so wie ... Tränen im Regen." *
*
************************************************************ ************

Re: doppelte Bearbeiung von Datensätzen vermeiden?

Mark Knochen schrieb:

> ich habe eine DB, an der mehrere Mitarbeiter gleichzeitig Daten
> einpflegen oder ändern.

Ach ja, die beliebten Race Conditions :-)

> Um Überschneidungen auszuschließen soll ein Datensatz, während
> er bearbeitet wird von den anderen Mitarbeitern nicht editiert oder
> gelöscht werden können.

Du willst also verhindern, dass der Datensatz überhaupt ein zweites Mal
aufgerufen werden kann? Spontan fällt mir hierzu Record Locking ein. Das
Problem dabei ist aber, dass PHP verbindungslos arbeitet. Sobald also
der PHP-Job beendet ist, ist auch das Locking wieder verschwunden.

> Ich dachte mir das so, dass immer, wenn ein Datensatz bearbeitet wird,
> die jeweilige ID des Datensatzes in eine Tabelle geschrieben wird,
> über die man dann abprüfen kann, welche Datensätze gerade in Bearbeitung
> sind. Ist die Bearbeitung abgeschlossen, wird die ID wieder aus der
> Tabelle gelöscht.

Ziemlich umständlich ...

> Aber was mache ich, wenn [...]

.... und problembehaftet, wie Du richtig bemerkt hast.

Ich würde eine andere Vorgehensweise vorschlagen: Du prüft vor dem
Zurückschreiben der Änderungen, ob der Datensatz nicht zwischenzeitlich
von jemand Anderem bereits verändert oder gar gelöscht wurde. Damit
verhinderst Du zwar nicht, dass zwei Personen sich gleichzeitig den Satz
zur Bearbeitung vornehmen, sorgst aber dafür, dass der eine nicht so
ohne Weiteres die Änderungen des Anderen überschreibt. Wenn Du es
besonders schick machen möchtest, bietest Du die Änderungen des Anderen
zum Mergen mit den eigenen Änderungen an.

Gruß. Claus
--
,~°O O
O ,´ / |/|\
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /

Re: doppelte Bearbeiung von Datensätzenvermeiden?

Mark Knochen wrote:

> Um Überschneidungen auszuschließen soll ein Datensatz, während
> er bearbeitet wird von den anderen Mitarbeitern nicht editiert oder
> gelöscht werden können.

man TRANSACTION
man TRANSACTION LEVEL

CIAO
andreas
--
.... oben geht es um den Thron - unten geht es um Deinen Hintern ...
[Keimzeit]
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de

Re: doppelte Bearbeiung von Datensätzen vermeiden?

Mark Knochen schrieb:
> Hallo,
>
> ich habe eine DB, an der mehrere Mitarbeiter gleichzeitig Daten
> einpflegen oder ändern.
>
> Um Überschneidungen auszuschließen soll ein Datensatz, während
> er bearbeitet wird von den anderen Mitarbeitern nicht editiert oder
> gelöscht werden können.
>

Ich hab ein ähnliches Problem wie folgt gelöst:
- jeder Mitarbeiter muss sich anmelden, Nutzung von Sessions
- jeder Datensatz hat eine Feld welches die Session-ID desjenigen
enthält der ihn bearbeitet - oder NULL wenn er nicht in
Bearbeitung ist
- es dürfen also nur Datensätze bearbeitet werden wo das Session-ID-Feld
NULL ist
- vor dem Bearbeiten muss dieses Feld via UPDATE mit der Session-ID
befüllt werden
- aufräumen von abgelaufenen Sessions durch einen eigenen
Session_handler (session_set_save_handler)
- beim löschen/ aufräumen der Sessions müssen gelockte Datensätze wieder
freigegeben werden
- das Timeout für Session niedrig halten (15 Minuten bei mir)

Das grob beschriebene Vorgehen funktioniert mit (fast) jeder DB,
getestet unter MySQL 4/5 und PostgreSQL.

hth Roy
--
Roy Kaldung
roy {at} kaldung {dot} com
http://kaldung.com/

Re: doppelte Bearbeiung von Datensätzen vermeiden?

Am Mon, 29 Jan 2007 22:42:35 +0100 schrieb Mark Knochen:

Hallo,

um welches DB System handelt es sich denn? Möglicherweise liefert ja das
DBMS ein entsprechendes Feature mit.

Z.B. bei Oracle 10i hat eine ORA_ROWSCN. Wenn ein Datensatz geupdateted
wurde, schreibt Oracle einen Timestamp in die Spalte.
Du musst beim auslesen des Datensatzes also die aktuelle ROWSCN auslesen
und in eine UPDATE - Query ein "WHERE ORA_ROWSCN = $ora_rowscn" einfügen.

Du kannst dies für jedes andere DBMS natürlich auch manuell pflegen.
Wichtig ist die ORA_ROWSCN ist kein eindeutiger Identifier.

HTH
Stefan

Re: doppelte Bearbeiung von Datensätzenvermeiden?

Andreas Froede wrote:
> man TRANSACTION LEVEL

Grr. ISOLATION LEVEL

CIAO
andreas
--
.... oben geht es um den Thron - unten geht es um Deinen Hintern ...
[Keimzeit]
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de

Re: doppelte Bearbeiung von Datensätzen vermeiden?

Andreas Froede schrieb:
> Andreas Froede wrote:
>> man TRANSACTION LEVEL
>
> Grr. ISOLATION LEVEL
>

Wieso siehst Du den Isolationlevel als Lösung an?
Er regelt nur, welchen Zustand der Datenbank Du siehst, aber beeinflusst
nicht das Sperrverhalten.

Die Frage die sich hier stellt, ist nur nach dem geeigneten
Sperrverhalten also optimistisch oder pessimistisch.

Bei einer Webaplikation würde ich auf Grund der Verbindungslosigkeit
immer von einem pessimistischen Sperrverhalten abraten.

Grüße

Bernhard