[Gelöst] Logisches Locking

[charlytango]

Hi,

in einem Mehrbenutzersystem soll verhindert werden dass ein User einen Datenbereich bearbeitet den ein anderer gerade in Arbeit hat.

Gelöst werden soll das über eine Tabelle TLocking in welche die BenutzerID, der Bereichsname und ggfs auch die HauptID des Bereichs geschrieben wird um einen Bereich zu locken.

Beispiel: Bei der Kundenbearbeitung bearbeitet man nicht nur den Kunden sondern auch seine Adressen, seine Kontaktdaten etc etc.

Wenn ein User das Formular eines Kunden öffnet und ändern will wird dieser Bereich vorher in TLocking gelocked.

Soweit ist das alles ok und lief über 10 Jahre lang mit dem Konzept.

Nun möchte ich das verbessern und verhindern dass zwei User zeitgleich einen bestimmten Kundenbereich locken können -- aus Laufzeitgründen kann es passieren dass einer das ok bekommt aber der andere auch und beide tragen einen Datensatz in TLocking ein was natürlich unsinnig ist.

Wie stelle ich es in MariaDB an dass so etwas nciht passieren kann.
Ich denke da an Table-Locking das möglichst schnell gehen soll um performant zu sein.

Ablauf:
1.)Frage: Gibt es einen Datensatz in TLocking für den gesuchten Bereich? Falls ja, Ende.
2.) Frage: Ist TLocking gelockt? wenn ja, irgendwie warten (auch nicht geklärt. Benutzerinfo wäre gut)
3.) TLocking fürs schreiben locken (können dann andere User noch gleichzeitig Abfragen ausführen zum Lesen?)
4.) Hat der Lock funktioniert?
5.) Neuen Datensatz eintagen
6.) Unlock TLocking

Und jetzt die Gretchenfrage:Mit welcher Syntax klappt das auf MariaDB/MySQL. Evtl auch mit einer Stored Procedure um das "Prepare" der DB einzusparen?

Das muss wirklich RockSolid sein

THX

[af0815]

Hm, RockSolid.

Dein Verfahren ist ja bereits RockSolid. Ich würde daran nicht viel ändern, nur den DB-Server die Arbeit umhängen:

In TLocking muss der der Bereichsname und der HauptID noch frei sein, dann besetzt buchen - das ganze in einer Transaktion. Nach dem Schreiben in der Tabelle TLocking die Tabelle direkt nach eine Refresh nochmals lesen und schauen ob du den Lock erhalten hast. Wenn ja, darfst du bearbeiten. Wenn der Bereichsname und die HauptID ein Unique Index sind, sollte ja jeder weitere Schreibversuch in einem Fehler enden und somit abgebrochen werden. Erst wenn das wieder gelöscht ist, sollte ein weiterer Versuch erfolgreich sein.

Dein Locking würde dann über die Beschränkung des zusammengesetzten unique Feld auf DB-Ebene funktionieren. Wichtig ist, das das erste Abfragen und Buchen in einer Transaktion ist und somit atomar behandelt wird. Wobei man überlegen muss ob nicht blind buchen alleine auch geht.

Da das 'Locking' über die Tabellenbeschränkung geht, kann du den resultierenden Fehler ja abfangen und auswerten.

Ungelöst wie immer was ist wenn der Lock hängenbleibt Mein berühmtes, Telefon läutet in der Bearbeitung, Chef macht auf wichtig, Laptopdeckel zu, ab zum Chef und der Lock hängt in alle Ewigkeit

[charlytango]

Oh danke, das mit dem zusammengesetzten unique Index hat Charme -- THX

Ungelöst wie immer was ist wenn der Lock hängenbleibt Mein berühmtes, Telefon läutet in der Bearbeitung, Chef macht auf wichtig, Laptopdeckel zu, ab zum Chef und der Lock hängt in alle Ewigkeit

Nein, gar nicht -- es gibt natürlich eine Möglichkeit die Locks auch anzeigen zu lassen und aus der Locking-Tabelle zulöschen, womit der Lock dann wieder offen ist. (Rechtegeschützt und auch vom Admin zu machen -- das hat eigentlich immer gut funktioniert).
Mein Problem ist dann eher was ist wenn der Chef wieder den Laptop aufmacht und dort weiterarbeiten will, da brauchts noch eine Sicherheitsstufe. Aber bis dahin ist es schonmal fein.

ZB ein Timer der läuft und einen im Editiermodus befindlichen Bereich absichert und ggfs in den Abbruchmodus zurücksetzt wäre ein Teil davon, aber auch nicht ausreichend.

[Socke]

Mein Problem ist dann eher was ist wenn der Chef wieder den Laptop aufmacht und dort weiterarbeiten will, da brauchts noch eine Sicherheitsstufe. Aber bis dahin ist es schonmal fein.

ZB ein Timer der läuft und einen im Editiermodus befindlichen Bereich absichert und ggfs in den Abbruchmodus zurücksetzt wäre ein Teil davon, aber auch nicht ausreichend.

Du kannst vor dem Speichern - idealerweise in der selben Datenbanktransaktion - nachschauen, ob deine Sperre noch da ist.

[charlytango]

Ich weiß ja warum ich diesem Forum bin.
Oft sieht man den Wald vor lauter Bäumen nicht.