Re: Datensatz sperren
- From: Paul Werkowitz <newsgroups@xxxxxxxxxxxxxxxx>
- Date: Tue, 05 Sep 2006 11:30:50 +0200
Peter Götz schrieb:
Hallo Paul,
Ich höre.das kommt immer drauf an. Optimistic Locking wird zwar immerMeist aus gutem Grund.
grundsätzlich empfohlen
Nenn mir mal einen guten Grund, der bei Desktop-Anwendungen sticht.
Wenn Du mit "Desktop-Anwendung" eine Anwendung wie z.b. Access meinst,
bei der ein einziger Benutzer ganz alleine auf seine lokal gespeicherte
*.mdb zugreift, dann brauchst Du Dir um Locking keine Gedanken zu
machen.
Der in der Praxis nicht ganz selten vorkommende Fall, dass mehrere
Desktop-Andwendungen auf eine auf einem Server gespeicherte, gemeinsam
genutzte Datenbank zugreifen, ist in den meisten Fällen mit
optimistischen Locking besser bedient.
Ein guter Grund kann nur einer sein, der mehr Vorteile bringt als er
kostet.
Nimm mal an eine DB-Tabelle enthält 10.000 Datensätze.
1000 Benutzer ändern ständig an dieser DB Datensätze mit
pessimistischen Locking und jeder braucht durchschnittlich 2 Minuten
vom Beginn der Änderung bis zur endgültigen Ausführung des
Update-Commands. So würden über die gesamte Zeit immer nahezu 10% aller
Datensätze gesperrt sein.
Macht man das selbe mit optimistischen Locking, dann ist ein Datensatz
keine 2 Minuten gesperrt sondern nur während des kurzen Moments der
Ausführung des Update-Commands. Sagen wir mal grosszügig 120
Millisekunden. Der Anteil von vorher nahe 10% gesperrter Datensätze
reduziert sich damit schon mal sehr drastisch und ich denke, das ist
ein handfester Vorteil, der sich darin bemerkbar macht, dass die
Benutzer wesentlich flüssiger arbeiten können, da sie nicht ständig
durch gesperrte Datensätze von ihrer Arbeit abgehalten werden.
OK, guter Versuch. ABER folgende Argumente dagegen:
- Das "Gesperrt-Sein" an sich ist ja nichts Negatives. Wenn ständig 10% aller Datensätze gesperrt sind, kann ich daraus zunächst mal keinen Nachteil erkennen. (Auch wenn die Zahlen bisschen hoch gegriffen für eine Desktop-Anwendung sein mögen).
- Wieso können Benutzer flüssiger arbeiten, wenn weniger gesperrt ist? Ich denke, das Gegenteil ist der Fall.
-*- In beiden Fällen treten Probleme nur dann auf, wenn 2 am gleichen Satz arbeiten wollen. Es reicht also, sich auf diesen Fall zu beschränken.
-*- Bei Optimistic Locking werden Probleme im Nachhinein erkannt, und müssen dann gelöst werden. Wie bereits mehrfach von mir dargestellt, bedeutet dis für den Benutzer idR ein neues Interface, dass er noch nie gesehen hat, evtl. daher Anruf bei der Hotline, etc. Entscheidungen müssen getroffen werden, die einen einfachen MItarbeiter evtl. überfordern. All das kostet Zeit und Energie des Mitarbeiters.
-*- Bei Pessimistic Locking werden Probleme von vornherein ausgeschlossen. Nur einer darf bearbeiten. Der Effekt, dass ein Mitarbeiter einen Sperrhinweis sieht, ist absolut tragbar, dann macht er in dieser Zeit was anderes.
Die Sache sieht anders aus, wenn wir von Desktop-Anwendung weggehen und z.B: in die industrielle Fertigung gehen. Dort laufen typischerweise viele Prozesse asynchron, wenn da einer wegen Sperren übermäßig warten muss, kann die Gesamtperformance extrem negativ beinflusst werden. Der Grund ist eben, dass ein Prozess, der eine Resource (hier: DB-Record) braucht, normalerweise eben nichts anderes machen kann, um den Zugriff später zu wiederholen. Zumindest kenne ich keine solchen Ansätze. Hier ist in der Tat optimistic Locking der bessere Weg.
Mein Argument war aber Folgendes: Die Aussage, dass Optimistic Locking GRUNDSÄTZLICH der bessere Ansatz ist, ist falsch.
[snip]
Wenn Müller einen Datensatz gerade ändert und Schulze holt sich diesen
Datensatz ebenfalls, um etwas daran zu ändern, dann haben erst mal
beiden den selben Zustand in Ihrem Datensatz und die Datenbank selbst
ist erst mal unverändert.
Nun ist Müller nicht gerade der Schnellste und trödelt herum, Schulze
aber ist flink, tippt seine Änderung flott ein und speichert schon vor
Müller. Bisher ist noch nicht unreparierbares passiert.
Jetzt hat es Müller endlich auch geschafft im 2-Finger-Suchsystem seine
Änderung einzutippen und versucht nun zu speichern. Der UpdateCommand
enthält eine Where-Klausel, welche alle Felder auf die OriginalValues
prüft. Müller wird also mit seinem UpdateCommand einen Fehler auslösen,
da der Datensatz zwischenzeitlich von Schulze verändert worden ist.
Bis hierher sind es technische Sachverhalte, die wir alle kennen. Nichts Neues: Wir können feststellen, dass eine Kollision aufgetreten ist. Und selbstverständlich ist die Situation "reparierbar" - technisch gesehen, zumindest.
Auf diese Fehlermeldung kann das Programm reagieren. Es kann Müller
fragen, ob er seine Änderung trotzdem speichern will und dann
entsprechend der Antwort speichern oder nicht speichern.
So, jetzt wirds interessant. Auch dies ist technisch möglich, und Müller kann auch mit den dazu nötigen Informationen versorgt werden.
Wir haben:
- den Originalsatz
- den Satz nach Änderungen von Meier
- und natürlich die Änderungen, die Müller gemacht hat.
Jetzt frage ich dich: wie willst du diese Informationen so aufbereiten, dass Müller eine gute Entscheidung treffen kann?
Je nach
Anwendungserfordernis, kann das Programm Müller auch den von Schulze
geänderten Datensatz zeigen und ihn dann nach seiner Entscheidung,
speichern oder nicht speichern, fragen.
Wie gesagt, technisch kein Problem.
Machen wir mal ein Beispiel aus der Praxis:
* Kundenkontostand vorher war -100 €
* Müller öffnet den Satz, bucht ein Storno wegen Warenrückgabe von 10 € und möchte speichern.
* Das Programm meldet ihm einen Konflikt, da der Kontostand nun nur noch -83 € ist.
Fragen:
- Was könnte hier passiert sein?
- Welcher Programmieraufwand entsteht, um die Situation zu visualisieren?
- Welche Optionen sollten Müller angeboten werden?
- Welches Risiko besteht, dass Müller falsch reagiert und Fehler entstehen, die später teuer von einem Supervisor korrigiert werden müssen?
Lösung zu 1: Jemand anderes hat das Storno eigegeben, dem Kunden aber gleichzeitig die 7 € Porto erstattet.
Herzlichen Glückwunsch!
[snip]
Wenn ich einen Update-Command mit der richtigen Where-Klausel (alle
Felder mit OriginalValue) ausführe, dann werde ich in den meisten
Fällen dies ungehindert tun können und in weit weniger Fällen wird
dieser UpdateCommand einen Fehler auslösen, weil ein anderer Benutzer
meinen Datensatz zwischenzeitlich geändert hat. Diesen Fehler kann mein
Programm erkennen und entsprechend darauf reagieren.
Gleiches Argument wie oben: Technisch natürlich möglich.
Eine Fehlererkennung und Fehlerbehandlung ist ohnehin erforderlich,
somit entsteht also so gut wie kein Mehraufwand.
Nein, eine solche Fehlerbehandlung wie bei optimistic Locking ist normalerweise eben NICHT notwendig. Ich habe dir oben in diesem Post ein Szenario mit einem Storno gegeben - die Nachbehandlung einer Kollision ist ziemlich aufwendig, vor allem beim Benutzer.
Das dieses den Datenbanktraffic locker
auf das Doppelte erhöht, wird nicht erwähnt.
Mit der üblichen Arbeitsweise (Where-Klausel über alle Felder) entsteht
im Normalfall (kein Mehrbenutzerkonflikt) kein erhöhter Netzwerk- oder
Datenbankverkehr.
Aha. Das must du mir mal zeigen, wie du das machst, die ganzen 80 Felder eines größeren Maskensets so in where-Bedingungen zu verpacken, dass das SQL-Statement dadurch nicht länger wird...... Sorry - der Netzwerkverkehr ist genau das: Transport von Daten zum oder vom Server.
Ist dagegen ständig ein grosser oder sogar der grösste Teil der
Datensätze gesperrt, produziert das in Summe weitaus mehr Verkehr, weil
die Benutzer mehrfach immer wieder versuchen müssen auf einen Datensatz
zuzugreifen, bis sie in endlich mal in nicht gesperrtem Zustand
erwischen.
Dann natürlich schon, aber das hat nichts mit pessimistic locking, sondern mit Polling zu tun. Wer pollt, erzeugt immer Last. So macht man das auch nicht. Ich verstehe mittlerweile besser, warum du pessimistic locking so schlecht siehst.
[Szenario mit A und B gesnippt]
Du konstruierst da Probleme, die nun wirklich alles andere als
tatsächliche Probleme sind und mit der täglichen Praxis nur äusserst
wenig zu tun haben.
Offensichtlich unterscheiden sich unsere Erfahrungen hier. Du stellst das ziemlich absolut dar - meine Erfahrungen sind anders. Das von mir dargestellte Szenario ist absolut realistisch: zwei Mitarbeiter, A und B, wollen am gleichen Satz arbeiten. Ich habe die sich aus der Verwendung von optimistic locking ergebenden Probleme dargestellt. Für mich ist das sogar SEHR realitätsnah.
Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmtmandann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
auseinanderzudividieren.
Lieber ständig den grössten Teil der in der DB vorhandenen Datensätze
ständig sperren, als hin und wieder mal auf einen durch
Mehrbenutzerkonflikt ausgelösten Fehler reagieren?
Genau.
Die Anzahl der gesperrten Sätze *an sich* ist ja nichts Negatives. Wichtig ist einzig und allein, wie das System mit einer Kollision umgeht. Was die Behandlung einer solchen kostet, und zwar in der Entwicklung, beim Kunden, und welche Risiken bestehen. Anmerkung: akademische Schönheit oder Eleganz ist bewußt *kein* Kriterium. Zahlt hier niemand Geld für.
Ich kann nur noch erstaunt mit dem Kopf schütteln.
Mach das. Danach schaust du dir die von mir mehrfach dargestellten Szenarien nochmal an, und zwar bezüglich der gerade genannten Kriterien, also Kosten SWE, Kosten im Feld, Risiken der Anwendung, Aufwand Schulung/Doku/Hotline etc.
Ich habe in einem anderen Posting das Szenario mit den 100 € auf dem Kundenkonto und zwei parallele Stornovorgänge gebracht. Vielleicht kannst du da mal zu Stellung nehmen bzgl. der genannten Kriterien.
ein,Wieviele und welche konkrete Anwendungsfälle fallen Dir auf Anhiebwäre?bei denen pessimistic Locking wirklich unumgänglich erforderlichKeine. Das war auch nicht das Thema.
Was war denn sonst das Thema?
Thema war: "Optimistic Locking ist grundsätzlich besser" Dem stimme ich nicht zu. Deine Aussage war: "Es gibt kein Szenario, wo man pessimistic locking braucht". Das sind zwei ganz verschiedene Sachen. Ich kenne z.B. einen Cobol-Programmierer, der mir immer wieder erzählt, dass man OOP nicht braucht und man alles mit Cobol machen kann. Ich gebe ihm jedesmal uneingeschränkt Recht. Ich sage ihm aber auch jedsmal, dass es darauf nicht ankommt.
Grüße - Paule
.
- References:
- Re: Datensatz sperren
- From: Paul Werkowitz
- Re: Datensatz sperren
- From: Peter Götz
- Re: Datensatz sperren
- From: Paul Werkowitz
- Re: Datensatz sperren
- From: Peter Götz
- Re: Datensatz sperren
- Prev by Date: Re: Datensatz sperren
- Next by Date: Re: Datensatz sperren
- Previous by thread: Re: Datensatz sperren
- Next by thread: Re: Datensatz sperren
- Index(es):
Relevant Pages
|
