Grundsätzliche Frage: Mysql und mehrere User

[pjensen]

Hallo,

mal ne grundsätzlich Frage:
Ich hab ne kleine Anwendung geschrieben mit Lazarus-Mysql (Zeos). Ist ne kleine Kundendatenbank (Name, PLZ, Strasse Ort etc). Allerdings tiefere Kenntnisse...

Das Prog kann ich unter Linux mehrfach starten. Wenn ich mit 2 Instanzen den gleichen Datensatz ändere, "gewinnt" immer der, der als letzter den Datensatz verläßt (ApplyUpdates).

Für mich ist das eher trivial, aber wie wird das für echte Mehrplatz-Systeme mit mysql realisiert. Eigentlich müßte doch jeder Datensatz, der aktuell von irgendjemand bearbeitet wird für andere gesperrt werden oder nur lesbar sein, oder ???

MfG, P. Jensen

[Christian]

Woher soll denn der SQL Server wissen, wann du einen Datensatz anschaust und wann du ihn bearbeitest ?
Gesperrt wird während des Commits, und der der zuletzt schreibt gewinnt. Das ist ne ganz normale Verhaltensweise.

[af0815]

Für mich ist das eher trivial, aber wie wird das für echte Mehrplatz-Systeme mit mysql realisiert. Eigentlich müßte doch jeder Datensatz, der aktuell von irgendjemand bearbeitet wird für andere gesperrt werden oder nur lesbar sein, oder ???

Mehrusersyteme sind nicht trivial zu bertachten.

Um solche Überschneidungen zu vermeiden sind eigene Überlegungen und Techniken nötig.

Du hast grob folgende Möglichkeiten:

A) Es ist so und nicht tun
B) Die Änderung im Rahmen einer Transaktion abwickeln
C) Auf Programmebene sperren einbauen
D) Auf (externe) Änderungen in der Datenmenge beim Update reagieren

Bei B kannst du das relativ einfach mit den vorhandenen Komponenten machen. Sprich eine Transaktion öffnen und wenn du fertig bist die Transaktion beenden.
C nimmt man meistens dann wenn Transaktionen nicht vom System unterstützt werden oder bei Desktopsystemen.
D ist in Datenbankverbindungskomponente verwirklicht. Stichwort Wie löse ich Konflikte beim speichern in der Datenbank.


Persöhnlich habe ich derzeit noch zuwenig mit Lazarus in dem Bereich gearbeitet, mein Wissen ist da noch zu Delphi & ADO & MsSQL lastig.

[monta]

Echter Mehrclient-betrieb ist ohnehin Sache das Datenbankservers. Dieser muss das ganze stehts konsistent verwalten und auch entsprechend reagieren, wenn mehrer Personen den gleichen Datensatz bearbeiten. Aber wenn du ihn bspw. mit UPDATE aktualisierst, ist ja klar, das das letzte Update übernohmen wird, weil dieses ja das vorhergehende Überschreibt ist ja aber letztlich auch der Sinn, wenn etwas aktualisiert wird.

Mehrere Transaktionen eines Datensatzes werden bis zum Commit gecacht und anschließend aufgelöst. Aber gerade dieses Transaktionhandling ist ein Buch für sich.

[piper62]

Hallo,
ich weiss nicht ob dieser Thread überhaupt noch gelesen wird...
Bin jetzt erst dazu gekommen, habe bisher nur auf dem internat. Lazarusforum geschaut.

Mit MySQL geht es grundsätzlich schon einen echten Multiuserbetrieb mit Transaktionen abzuwickeln.
Als Erstes wird dazu eine richtige StorageEngine von MySQL benötigt die auch Transaktionen versteht. Ansonsten geht mit der Standard MyISAM Engine nur ein Table-Lock.
Der erste User der einen Datensatz bearbeiten möchte sollte für ein Update - und nur dies ist kritisch- den Datensatz sperren können. Der nächste User der darauf zugreifen möchte bekommt dann eine Fehlermeldung solange bis der Datensatz wieder freigegeben wurde.
Die transaktionssicheren Tabellen sind bei MySQL die InnoDB Tabellen. Das kann bei der Anlage der Tabellen angegeben werden oder über ein Alter Table geändert werden.
Dann muss für das Update ein spezielles Schlüsselwort verwand werden.
Das würde dann zum Beispiel so lauten:
"select * from person where pid=12 for update"
Entscheidend ist hier das "for update" damit weiss MySQL, dass der Datensatz geperrt werden muss.
Die Sperre gilt solange bis von der Session ein "COMMIT" oder ein "ROLLBACK" kommt oder die Session abgebrochen wird. Das Letztere ist gleichbedeutend mit einem "ROLLBACK".

Das Ganze funktioniert wunderbar mit MySQL 5.X und Zeos.

Hoffe damit geholfen zu haben.

Gruss,
Tibor

[khh]

da will ich mich grad mal dranhängen.
ob per autocommit oder per transaction die daten zu speichern funktioniert einwandfrei.

bei mehreren Arbeitsplätzen habe ich aber das Problem, dass die "passiven" Plätze von den geänderten daten in der DB nix mitbekommen.
Wie ist das zu handeln?



Gruss KH

[Christian]

Im normalfall müssen sie das nicht sofort Beispiel Auftragsverwaltung Wenn man nach neuen auftrtägen sucht dann eh per abfrage auf die DB womit man immer den letzten Status der DB bekommt, ansonsten muss ein Benutzer nicth wissen was an neuen Aufträgen erfasst wurde.
Bei Sachen wie Mail system oder Kalendar kann man entweder periodisch abfragen was sich geändert hat oder man erstellt Trigger, die jedoch nicht von jedem DB System unterstützt werden.

[khh]

Im normalfall müssen sie das nicht sofort Beispiel Auftragsverwaltung Wenn man nach neuen auftrtägen sucht dann eh per abfrage auf die DB womit man immer den letzten Status der DB bekommt, ansonsten muss ein Benutzer nicth wissen was an neuen Aufträgen erfasst wurde.
Bei Sachen wie Mail system oder Kalendar kann man entweder periodisch abfragen was sich geändert hat oder man erstellt Trigger, die jedoch nicht von jedem DB System unterstützt werden.

und was ist in der Stammdatenverwaltung, beispielsweise beim ändern von Kundendaten?

Gruss KH

[Christian]

Was soll damit sein, wenn User X etwas an seinem Kunden ändert muss nicht gleich der ganze vertrieb darüber bescheid wissen.

[khh]

Was soll damit sein, wenn User X etwas an seinem Kunden ändert muss nicht gleich der ganze vertrieb darüber bescheid wissen.

ich danke dir,


Gruss KH

[af0815]

[quote="khh]und was ist in der Stammdatenverwaltung, beispielsweise beim ändern von Kundendaten?[/quote]
Ich verstehe jetzt dein Problem nicht ganz.

Es ist ganz normal, das in einer Multiuserdatenbank sich Daten ändern, auch Stammdaten.
Diese Situation musst du ganz einfach berücksichtigen, grob gesagt:
Wenn es heikel wird, musst du mit Transaktionen und somit Sperren arbeiten, damit die keiner die Daten unterm hintern wegändert. Oder du berücksichtigst die Probleme beim Einbringen der Daten und löst die Konflikte auf. Oder du holst dir halt die Daten immer aktuell, aber was ist aktuell ? Jetzt, vor 1ms, vor 1 Tag ?

[khh]

Wenn es heikel wird, musst du mit Transaktionen und somit Sperren arbeiten, damit die keiner die Daten unterm hintern wegändert.

genau das war meine befürchtung.
Wenn 2 Benutzer gleichzeitig Stammdaten ändern, wollte ich diese jeweils beim andern aktuallisiert anzeigen.
Ich denke jetzt aber, dass das relativ aufwändig ist, und man die Verantwortung wohl an den User abtreten kann.
ich überlege noch, ob es sinn macht die in Bearbeitung befindlichen ds zu sperren und dem "zu spät kommenden" user die Sperre anzuzeigen.

Gruss KH

[af0815]

Wenn es heikel wird, musst du mit Transaktionen und somit Sperren arbeiten, damit die keiner die Daten unterm hintern wegändert.

... ich überlege noch, ob es sinn macht die in Bearbeitung befindlichen ds zu sperren und dem "zu spät kommenden" user die Sperre anzuzeigen ...

Eigenlich sollte nur dann der User 'belästigt' werden, wenn seine Änderung nicht ok ist. Was man in keinem Fall machen darf ist , dem User ein Transaktion starten, editieren und dann abschliessen lassen. Das kann ins Auge gehen.
Was ist der hat inzwischen einen Telefonanruf und vergisst dann die Transaktion zu beenden und macht es erst nach seinem Urlaub lol.

Meine Erfahrung ist: Lass den User nach Änderungen sofort auf den 'Speichern' Button drücken. Wenn er die Daten nicht speichern kann, weil wer was im Hintergrund geändert hat, so sage es ihm sofort und nicht 100 Eingaben später und du hast deine Ruhe.

Ein der vielen Möglichkeit Änderungen zu erkennen, ist Timestamps in der Zeile in der DB zu speichern und bei jeder Änderung, diesen zwangsweise (durch den Server, Trigger) zu ändern. Damit bekommst du jede Änderung mit.