Datensatz sperren
Peer Schlephack
kann mir jemand sagen, wie ich einen Datensatz im SQL Sperren kann, damit
nicht mehrere Benutzer diesen Datensatz bearbeiten können?
Vielen Dank
Norbert Eder
(grundlegende Informationen gibt es unter
http://www.databasejournal.com/features/mssql/article.php/3289661) oder aber
du führst ein entsprechendes Flag ein, welches du zur Signalisierung "ich
bin gelockt" gebrauchst. Kommt auf deinen konkreten Anwendungsfall an.
Natürlich musst du im zweiten Fall auch dafür sorgen, dass der Lock wieder
entfernt wird, wenn beispielsweise die Client-Applikation abstürzt, Session
abläuft, was auch immer.
"Peer Schlephack" <sylve...@gmx.de> schrieb im Newsbeitrag
news:%23$3FLmOzG...@TK2MSFTNGP06.phx.gbl...
Daniel Kuppitz
> kann mir jemand sagen, wie ich einen Datensatz im SQL Sperren kann, damit
> nicht mehrere Benutzer diesen Datensatz bearbeiten können?
Schau Dir das mal an:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconOptimisticConcurrency.asp
Wenn mehrere Benutzer an den gleichen Daten arbeiten und die
Bearbeitung eine Weile dauert, sollte man die Datensätze möglichst
nicht sperren. Mehr dazu im genannten Link.
--
MfG,
Daniel Kuppitz
Paul Werkowitz
> Wenn mehrere Benutzer an den gleichen Daten arbeiten und die
> Bearbeitung eine Weile dauert, sollte man die Datensätze möglichst
> nicht sperren. Mehr dazu im genannten Link.
>
Hallo Daniel,
das kommt immer drauf an. Optimistic Locking wird zwar immer
grundsätzlich empfohlen und hier auch immer schön nachgebetet,
allerdings werden die Nachteile meist schöngeredet.
Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher kommt
praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
können. Man stellt es als "korrekt" dar, und schon hört man überall "Du
splltest Datensätze möglichst nicht sperren..." Kannst du das in solcher
Allgemeinheit wirklich behaupten? Ich denke, nein.
My 2 cents...
Paule
Peter Götz
> das kommt immer drauf an. Optimistic Locking wird zwar immer
> grundsätzlich empfohlen
Meist aus gutem Grund.
> und hier auch immer schön nachgebetet,
> allerdings werden die Nachteile meist schöngeredet.
Welche konkreten Nachteile?
> Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher
kommt
> praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
> können. Man stellt es als "korrekt" dar, und schon hört man überall
"Du
> splltest Datensätze möglichst nicht sperren..." Kannst du das in
solcher
> Allgemeinheit wirklich behaupten? Ich denke, nein.
Wieviele und welche konkrete Anwendungsfälle fallen Dir auf Anhieb ein,
bei denen pessimistic Locking wirklich unumgänglich erforderlich wäre?
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Daniel Kuppitz
> > Wenn mehrere Benutzer an den gleichen Daten arbeiten und die
> > Bearbeitung eine Weile dauert, sollte man die Datensätze möglichst
> > nicht sperren. Mehr dazu im genannten Link.
> >
>
> das kommt immer drauf an. Optimistic Locking wird zwar immer
> grundsätzlich empfohlen und hier auch immer schön nachgebetet,
> allerdings werden die Nachteile meist schöngeredet.
>
> Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher kommt
> praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
> können. Man stellt es als "korrekt" dar, und schon hört man überall "Du
> splltest Datensätze möglichst nicht sperren..." Kannst du das in solcher
> Allgemeinheit wirklich behaupten? Ich denke, nein.
Doch, die Freiheit nehm ich mir.
Als ich beispielsweise in die Firma kam, wo ich zur Zeit arbeite, war
der DAL voll mit Locks, mittlerweile gibt es kein einziges Lock mehr.
Locks mögen einem in vielen Fällen das Leben einfacher machen, aber
sie sind einfach unschön und ich bin der Meinung, dass sie nicht
wirklich notwendig sind; irgendwie lässt es sich immer anders lösen.
Ok, kurz vorm Abschicken ist mir noch ein Szenario eingefallen, wo ich
tatsächlich nicht drum herum gekommen bin, aber trotzdem: Locks so oft
wie möglich vermeiden. Wenn es anders geht, sollte man es auch anders
machen. (Bei meinem Fall geht es auch nicht um Benutzereingaben).
--
MfG,
Daniel Kuppitz
Sascha Münch
Daniel Kuppitz schrieb:
> Locks mögen einem in vielen Fällen das Leben einfacher machen, aber
> sie sind einfach unschön und ich bin der Meinung, dass sie nicht
> wirklich notwendig sind; irgendwie lässt es sich immer anders lösen.
>
> Ok, kurz vorm Abschicken ist mir noch ein Szenario eingefallen, wo ich
> tatsächlich nicht drum herum gekommen bin, aber trotzdem: Locks so oft
> wie möglich vermeiden. Wenn es anders geht, sollte man es auch anders
> machen. (Bei meinem Fall geht es auch nicht um Benutzereingaben).
Das stellt mich jetzt vor die Frage, was Du bei Benutzereingaben machst.
Lock oder nicht Lock? Oder Reden wir hier nur über das Locking-Verhalten
des SQL-Servers? Falls ja, einfach nicht weiterlesen ;-)
Beispiel ais meinem Job: ein Dokument kann von vielen Anwnedern geöffnet
werden zwecks Änderung. Wenn jemand in der Dokumentenübersicht sich das
Dokument zum Ändern öffnet, dann wird ein User und Zeitstempel in den DS
geschrieben und damit der DS anwendungsseitig gelockt. Sollte die
Applikation mal (aufgrund von Chrashs, Netzwerkzusammenbrüchen, ...) den
Lock nicht entfernen können, kann ein Admin in einer Adminanwendung alle
Locks des Users löschen. Kommt bei dem Kunden von heute (>800 User, ca.
2500 neue Dokumente pro Monat die durch das System geschleust werden) so
einmal die Woche vor. Wichtig ist auch, dass keine eingegebenen Daten
von anderen Usern überschrieben werden, ohne das die nicht alle vom
Vorgänger geänderten Daten gesehen hat. (Handelt sich um eine
FiBU-Anwendung, sprich es arbeiten Buchhalter damit ....)
Wie willst du das ohne Locks hinbekommen? Vor dem Rückschreiben den
Datensatz nochmal lesen und mit der eigenen Version vergleichen? Bei der
doppelten Arbeit die die Leute dann bei uns hätten, würden die uns am
nächsten Baum aufknüpfen.
CU
Sascha
Daniel Kuppitz
? Nö... Stichwort "Optimistic Concurrency". Es gibt ja nun mehrere
Ansätze wie man es umsetzen kann. Mein Favorit: der Timestamp.
Annahme: Folgende Tabellenfelder:
ID Vorname Nachname Adresse Timestamp
Benutzer A und Benutzer B öffnen den gleichen Datensatz zum
bearbeiten, im SELECT ist die Timestampspalte mit drin. Benutzer A
speichert:
UPDATE Tabelle SET Vorname=@vn, Nachname=@nn, Adresse=@ad WHERE ID=@id
AND Timestamp=@ts;
Benutzer speichert jetzt auch:
UPDATE Tabelle SET Vorname=@vn, Nachname=@nn, Adresse=@ad WHERE ID=@id
AND Timestamp=@ts;
Resultat: 0 affected rows
Schlussfolgerung: Datensatz wurde zwischenzeitlich bearbeitet.
Reaktion: Auslesen des neuen Timestamp und Frage an Benutzer B, ob DS
trotzdem gespeichert werden soll, evtl. Anzeige der aktuellen Daten.
Wenn ja:
Gleiches Query nocheinmal mit eben noch ausgelesenem (neuen) Timestamp.
Kommt es wieder zum Fehler hat wahrscheinlich Benutzer C
zwischenzeitlich auch nochmal gespeichert und so weiter und so fort.
Eine andere Möglichkeit wäre sich die Originalwerte, also die Werte
zum Zeitpunkt des initialen Auslesens zu merken und dann ein Query in
der Art abzuschicken:
UPDATE Tabelle SET Vorname=@vn, Nachname=@nn, Adresse=@ad WHERE ID=@id
AND Vorname=@old_vn AND Nachname=@old_nn AND Adresse=@old_ad;
Dann verbraucht meine Anwendung mehr Speicher (u.U. sehr viel mehr),
aber ich muss die Datenbank nicht extra anpassen.
In keinem der Fälle gibt es ein Lock auf Datenbankebene.
Wo es bei uns noch benötigt wird, ist im Frontend (Webshop). Bei
Bestellabschlussmuss sicher gestellt sein, dass eine Bestellnummer
eindeutig ist und da das Feld Bestellnummer kein autoincrementelles
Feld (da selten einfache Zahlen, sondern eher Mix aus Zahlen aus
Buchstaben) ist, heißt das:
lock
letzte Nummer auslesen
Bestellung mit nächster Nummer schreiben
unlock
--
MfG,
Daniel Kuppitz
Peter Götz
> Beispiel ais meinem Job: ein Dokument kann von vielen Anwnedern
> geöffnet werden zwecks Änderung. Wenn jemand in der
> Dokumentenübersicht sich das Dokument zum Ändern öffnet, dann
> wird ein User und Zeitstempel in den DS geschrieben und damit
> der DS anwendungsseitig gelockt. Sollte die Applikation mal
> (aufgrund von Chrashs, Netzwerkzusammenbrüchen, ...) den
> Lock nicht entfernen können, kann ein Admin in einer
> Adminanwendung alle Locks des Users löschen.
Das kann man auch ohne Admin lösen, indem man für diesen Zeitstempel
eine entsprechende Behandlungsvorschrift einhält.
Man legt z.B. fest, dass Datensätze ohne Zeitstempel oder solche mit
einem Zeitstempel, der älter als 5 Minuten ist, als nicht gesperrt
gelten. Beginnt ein Benutzer mit der Änderung setzt sein Programm den
Zeitstempel. Nun hat der Benutzer etwas weniger als 5 Minuten Zeit,
seine Änderungen einzugeben und zu speichern. Kurz vor Ablauf der 5
Minuten kann das Programm den Zeitstempel um weitere 5 Minuten
verlängern und so einem evtl. etwas weniger flinken Benutzer auch noch
mehr Zeit geben. Dieses Verlängern des Zeitstempels sollte natürlich
auch auf irgend ein vernünftiges Mass begrenzt werden. Mit dem
Speichern einer begonnenen Änderung wird der Zeitstempel für diesen
Datensatz gelöscht und ist nun wieder frei. Stürzt ein Rechner, der
gerade eine Änderung begonnen und den Datensatz mit einem Zeitstempel
markiert hat ab, dann ist das weiter kein Problem, denn spätestens nach
5 Minuten gilt der Zeitstempel als veraltet und er Datensatz als frei.
Die Zeit von 5 Minuten und die Anzahl der möglichen Verlängerungen ist
entsprechend der jeweiligen Anwendungsgegebenheiten frei wählbar.
Neben einem Rechnerabsturz könnte auch noch der Fall eintreten, dass
ein Benutzer eine Änderung beginnt und dann telefoniert und telefoniert
und telefoniert und ......
Auch das ist kein Problem. Nach Ablauf der 5 Minuten bzw. nach Ablauf
der möglichen Verlängerungszeiten beendet das Programm die Eingabe,
verwirft die bisher vorgenommenen Eingaben, löscht den Zeitstempel und
weist den Benutzer per Dialogbox darauf hin, dass er den Datensatz zu
lange blockiert hat und nochmal von vorne beginnen muss.
> Kommt bei dem Kunden von heute (>800 User, ca.
> 2500 neue Dokumente pro Monat die durch das System geschleust werden)
so
> einmal die Woche vor.
s.oben: das kann man auch ohne Admin lösen.
> Wichtig ist auch, dass keine eingegebenen Daten
> von anderen Usern überschrieben werden, ohne das die nicht alle vom
> Vorgänger geänderten Daten gesehen hat. (Handelt sich um eine
> FiBU-Anwendung, sprich es arbeiten Buchhalter damit ....)
Das lässt sich dadurch lösen, dass der UpdateCommand für diese
Änderung eine über alle Felder des Datensatzes gehende Where-Klausel
enthält. Die Ausführung dieses Commands löst einen Fehler aus, wenn
auch nur ein einziges Feld des Datensatzes in der Zwischenzeit
verändert worden ist. Nur in diesem Fall muss der Benutzer dann
entscheiden, ob er seine Änderungen trotzdem speichern will oder eben
nicht. Je nach Anwendungserfordernis kann man in diesem Fall dem
Benutzer auch die zwischenzeitlich an seinem Datensatz von anderen
vorgenommenen Änderungen zeigen.
> Wie willst du das ohne Locks hinbekommen?
Dazu ist keine pessimistische Sperre notwendig. Eine simple
Where-Klausel im UpdateCommand verhindert das unerkannte Überschreiben
von Änderungen anderer Benutzer.
> Vor dem Rückschreiben den
> Datensatz nochmal lesen und mit der eigenen Version vergleichen?
Nein, das ist nicht notwendig, weil der UpdateCommand mit
entsprechender Where-Klausel ohnehin einen Fehler auslöst, wenn der
Datensatz von anderen Benutzern verändert worden ist.
> Bei der doppelten Arbeit die die Leute dann bei uns hätten,
> würden die uns am nächsten Baum aufknüpfen.
Die Praxis zeigt, dass bei dem von Dir geschilderten Szenario der
grösste Teil der Änderungen ohne "Zwischenfall" abgearbeitet werden
kann und nur in wenigen Fällen es tatsächlich dazu kommt, dass ein zu
speichernder Datensatz zwischenzeitlich von anderen Benutzern verändert
worden ist. Für diese wenigen Fällen ständig sämtliche gerade in Arbeit
befindliche Datensätze zu sperren ist wenig ökonomisch und ganz sicher
kein Fall bei dem pessimistisches Locking wirklich unumgänglich wäre.
Paul Werkowitz
> Hallo Paul,
>
>> das kommt immer drauf an. Optimistic Locking wird zwar immer
>> grundsätzlich empfohlen
>
> Meist aus gutem Grund.
Ich höre.
Nenn mir mal einen guten Grund, der bei Desktop-Anwendungen sticht.
Ein guter Grund kann nur einer sein, der mehr Vorteile bringt als er
kostet.
Wie gesagt, Webanwendungen sind eine andere Baustelle.
>
>> und hier auch immer schön nachgebetet,
>> allerdings werden die Nachteile meist schöngeredet.
>
> Welche konkreten Nachteile?
Grundsätzlich reduziert sich die Menge der Probleme und Nachteile auf
folgende, hier vereinfacht dargestellte Überlegung:
In einem Multi-User Szenario musst du damit rechnen, dass zwei user was
machen wollen, was potentiell die gleichen Ressourcen benötigt.
Beschränken wir uns hier also mal auf die Resourcen "Datenbankrecords",
die - mal angenommen - nicht von mehreren "gleichzeitig" verändert
werden sollen.
Während asynchrone Zugriffe auf solche Resourcen in der Informatik
grundsätzlich mit Locking, Semaphoren oder ähnlichen Mechanismen
serialisiert werden, wollen dies viele Datenbankler besser wissen und
verlangen die Möglichkeit, eine Resource unabhängig und wie im
Singleuser-Betrieb verfügbar zu haben.
Als Folge werden Mechanismen benötigt, um die parallel Benutzung einer
Resource (Hier: Veränderung eines Records) zu erkennen und eventuelle
Komplikationen *nachträglich* zu behandeln. Empfohlen wird gerne, vor
dem Speichern eines Satzes diesen *komplett* (!) nocheinmal zu lesen und
mit dem eigenen Originalstand (den man sich dann getrennt und zusätzlich
merken muss (!!)) zu vergleichen. Das dieses den Datenbanktraffic locker
auf das Doppelte erhöht, wird nicht erwähnt.
Während man dies noch durch ein paar zusätzliche Euronen, die man in
einen stärkeren Server investiert, leicht in den Griff bekommt, wird es
bei der Überlegung, wie denn nach einer Kollisionserkennung zu verfahren
sei, schon schwieriger. Peter und/oder Daniel mögen mir zum Beispiel
einmal erklären, was ich als Softwareentwickler in folgendem Szenario
tun sollte:
1. - Buchungskraft A ruft Kunde auf den Bildschirm, und korrigiert auf
Grund von vorliegendem Beschwerdebrief die Rechnungsstellung. Z.B. sind
nicht 63 Stunden, sondern in Wirklichkeit nur 36 Stunden gearbeitet
worden. Einige weitere Änderungen sollen gemacht werden.
2. - In dieser Zeit ruft der Kunde bei Buchungskraft B an, und beschwert
sich. B ruft Kunde auf den Bildschirm, und sieht, dass irrtümlich 63
statt 36 Stunden notiert sind. B korrigiert dies, redet eine Weile mit
dem Kunden, macht vielleicht noch eine Notiz etc.
3. - Zwischenzeitlich ist A fertig und speichert den Satz.
4. - Auch B beendet irgendwann das Gespräch, und möchte die vereinbarten
Änderungen speichern.
Was soll die Software jetzt tun? Es kann relativ problemlos erkannt
werden, dass der Satz zwischenzeitlich geändert wurde. Man kann nun den
Satz nicht einfach neu laden und von B verlangen
- alles durchzulesen, um zu sehen, ob evtl. Teile oder alle gewünschten
Änderungen bereits von anderer Stelle durchgeführt wurden
- das, was noch nicht drin ist, neu einzugeben. Denn: Der Kunde hat
aufgelegt, und B hat sich keine Notizen gemacht, sondern
selbstverständlich die Erkenntnisse aus dem Gespräch sofort in die Maske
eingetragen.
Klar - es gibt auch hier Lösungsstrategien, z.B. die Differenzen zu
bestimmen und diese gesondert anzuzeigen etc. IN der Praxis alles
schwierig, da - mal abgesehen vom Programmieraufwand - viele Benutzer
damit überfordert sind.
Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt man
dann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
auseinanderzudividieren.
> Wieviele und welche konkrete Anwendungsfälle fallen Dir auf Anhieb ein,
> bei denen pessimistic Locking wirklich unumgänglich erforderlich wäre?
>
Keine. Das war auch nicht das Thema.
Grüße
Paul
Daniel Kuppitz
> Während man dies noch durch ein paar zusätzliche Euronen, die man in
> einen stärkeren Server investiert, leicht in den Griff bekommt, wird es
> bei der Überlegung, wie denn nach einer Kollisionserkennung zu verfahren
> sei, schon schwieriger. Peter und/oder Daniel mögen mir zum Beispiel
> einmal erklären, was ich als Softwareentwickler in folgendem Szenario
> tun sollte:
Immerwieder gern ;-).
> 1. - Buchungskraft A ruft Kunde auf den Bildschirm, und korrigiert auf
> Grund von vorliegendem Beschwerdebrief die Rechnungsstellung. Z.B. sind
> nicht 63 Stunden, sondern in Wirklichkeit nur 36 Stunden gearbeitet
> worden. Einige weitere Änderungen sollen gemacht werden.
>
> 2. - In dieser Zeit ruft der Kunde bei Buchungskraft B an, und beschwert
> sich. B ruft Kunde auf den Bildschirm, und sieht, dass irrtümlich 63
> statt 36 Stunden notiert sind. B korrigiert dies, redet eine Weile mit
> dem Kunden, macht vielleicht noch eine Notiz etc.
>
> 3. - Zwischenzeitlich ist A fertig und speichert den Satz.
>
> 4. - Auch B beendet irgendwann das Gespräch, und möchte die vereinbarten
> Änderungen speichern.
>
>
> Was soll die Software jetzt tun? Es kann relativ problemlos erkannt
> werden, dass der Satz zwischenzeitlich geändert wurde. Man kann nun den
> Satz nicht einfach neu laden und von B verlangen
Wie schon im letzten Beitrag erwähnt, finde ich es am elegantesten
entsprechende Tabellen mit einer Timestamp Spalte zu versehen (so wird
der Traffix auch nicht gleich nahezu verdoppelt). Die Kollision wird
also anhand der Timestamp Spalte erkannt. So weit, so gut...
Jetzt sind wir an dem Punkt, wo es zum Mehraufwand kommt. Eine schöne
Lösung wäre es, den Eintrag aus der DB zu holen, alle Felder
anzuzeigen und die Unterschiede bezogen auf den lokalen Stand
hervorzuheben. Der Anwender kann dann entscheiden, ob er seine
Änderungen verwirft, speichert oder noch einmal bearbeitet.
> - alles durchzulesen, um zu sehen, ob evtl. Teile oder alle gewünschten
> Änderungen bereits von anderer Stelle durchgeführt wurden
Für lange Texte lassen sich bestimmt ein paar Komponenten finden, die
einem eine Anzeige wie in Versionsverwaltungssystemen liefern können,
wie z.B. unter [1].
> - das, was noch nicht drin ist, neu einzugeben. Denn: Der Kunde hat
> aufgelegt, und B hat sich keine Notizen gemacht, sondern
> selbstverständlich die Erkenntnisse aus dem Gespräch sofort in die Maske
> eingetragen.
Nein, wenn ich schon beide Versionen gegenüber stelle, ist es auch
kein Problem mehr, den Anwender auswählen zu lassen, welchen Eintrag
er in die DB übernehmen will. Notfalls könnte er auch Teile des
angezeigten Textes (DB Stand) mit Copy/Paste in seine Änderung
übernehmen.
> Klar - es gibt auch hier Lösungsstrategien, z.B. die Differenzen zu
> bestimmen und diese gesondert anzuzeigen etc. IN der Praxis alles
> schwierig, da - mal abgesehen vom Programmieraufwand - viele Benutzer
> damit überfordert sind.
Mehr Programmieraufwand = mehr Kosten für den Kunden. Aber die Praxis
zeigt auch, das viele Kunden einwilligen, wenn man gute Argumente hat
und das Argument an dieser Stelle wäre eindeutig die Usability. Ich
wüsste nicht, welchen Anwender ein solches Verhalten der Anwendung
überfordern soll.
Mir als "Buchungskraft B" wäre es lieber, wenn ich den Datensatz
erstmal bearbeiten kann, statt nicht zu wissen warum der Datensatz
gesperrt ist, bzw. von wem er gerade bearbeitet wird.
> Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt man
> dann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
> auseinanderzudividieren.
Nur zu, bauen wir es solange aus, bis wir ein Deadlock Szenario haben
und die "optimistische Seite" das Killerargument in der Hand hat ;-).
[1] http://www.codeproject.com/useritems/Diff_Patch_Utility_in_C_.asp
--
MfG,
Daniel Kuppitz
Paul Werkowitz
>>
>> Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher kommt
>> praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
>> können. Man stellt es als "korrekt" dar, und schon hört man überall "Du
>> splltest Datensätze möglichst nicht sperren..." Kannst du das in solcher
>> Allgemeinheit wirklich behaupten? Ich denke, nein.
>
> Doch, die Freiheit nehm ich mir.
> Als ich beispielsweise in die Firma kam, wo ich zur Zeit arbeite, war
> der DAL voll mit Locks, mittlerweile gibt es kein einziges Lock mehr.
> Locks mögen einem in vielen Fällen das Leben einfacher machen, aber
> sie sind einfach unschön und ich bin der Meinung, dass sie nicht
> wirklich notwendig sind; irgendwie lässt es sich immer anders lösen.
Hallo Daniel,
genau das ist es, was ich meine. Warum sind Locks "einfach unschön"?
Nenne mir Nachteile, aber vergleiche immer mit den Alternativen - IMHO
sind die in der Regel noch nachteiliger. "Nicht wirklich notwendig"?
Stimmt! Kann man alles auch anders machen - aber die grundsätzliche
Frage bleibt: Ist es dann besser?
In Eurer Firma scheint es möglich gewesen zu sein, auf Locking zu
verzichten. Schön! Dann ist es gut, ohne zu arbeiten. Es ging in diesem
Thread jedoch darum, ob optimistic locking *grundsätzlich* besser ist -
und das bezweifle ich. Ich behaupte sogar, dass es in den meisten
Desktop-Szenarien schlechter als Sperren ist.
>
> Ok, kurz vorm Abschicken ist mir noch ein Szenario eingefallen, wo ich
> tatsächlich nicht drum herum gekommen bin, aber trotzdem: Locks so oft
> wie möglich vermeiden. Wenn es anders geht, sollte man es auch anders
> machen. (Bei meinem Fall geht es auch nicht um Benutzereingaben).
"So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
vermeiden sollte, und insbesondere interessiert mich, warum die
Alternative besser ist.
Grüße
Paule
Paul Werkowitz
> Hi Daniel,
> Beispiel ais meinem Job: ein Dokument kann von vielen Anwnedern geöffnet
> werden zwecks Änderung. Wenn jemand in der Dokumentenübersicht sich das
> Dokument zum Ändern öffnet, dann wird ein User und Zeitstempel in den DS
> geschrieben und damit der DS anwendungsseitig gelockt. Sollte die
> Applikation mal (aufgrund von Chrashs, Netzwerkzusammenbrüchen, ...) den
> Lock nicht entfernen können, kann ein Admin in einer Adminanwendung alle
> Locks des Users löschen. Kommt bei dem Kunden von heute (>800 User, ca.
> 2500 neue Dokumente pro Monat die durch das System geschleust werden) so
> einmal die Woche vor.
UNd was passiert, wenn der Admin krank und der Vertreter in einer
Besprechung ist? Ein EDV-System auf die 100%-Verfügbarkeit eines
menschlichen Problembehebers abzustellen scheint mir nicht die optimale
Lösung zu sein.
Ich weiß nicht, wie Eure Nutzer das sehen, aber unsere würden sowas
nicht akzeptieren. OK - wir laufen in Kliniken mit 24x7 - Betrieb. Das
muss das IMMER funktionieren.
>Wichtig ist auch, dass keine eingegebenen Daten
> von anderen Usern überschrieben werden, ohne das die nicht alle vom
> Vorgänger geänderten Daten gesehen hat. (Handelt sich um eine
> FiBU-Anwendung, sprich es arbeiten Buchhalter damit ....)
>
> Wie willst du das ohne Locks hinbekommen? Vor dem Rückschreiben den
> Datensatz nochmal lesen und mit der eigenen Version vergleichen? Bei der
> doppelten Arbeit die die Leute dann bei uns hätten, würden die uns am
> nächsten Baum aufknüpfen.
>
Ack.
Grüße - Paule
Elmar Boye
Paul Werkowitz <newsg...@primaprogramm.de> schrieb ...
> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
> vermeiden sollte, und insbesondere interessiert mich, warum die
> Alternative besser ist.
Bitte informiere Dich erstmal was ein Sperre so alles anstellen kann,
was die Skalierbarkeit einer Anwendung angeht:
http://blogs.msdn.com/queryoptteam/archive/2006/03/24/560396.aspx
Denn nimms mir nicht übel: Deine Argumentation deutet auf
einige Unkenntnis hin, was das Thema angeht.
Gruss
Elmar
Elmar Boye
Elmar Boye <Elm...@gmx.net> schrieb ...
> was die Skalierbarkeit einer Anwendung angeht:
> http://blogs.msdn.com/queryoptteam/archive/2006/03/24/560396.aspx
Korrektur, da falscher Link im Clipboard:
http://blogs.msdn.com/queryoptteam/archive/2006/08/01/685659.aspx
Gruss
Elmar
Daniel Kuppitz
> >>
> >> Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher kommt
> >> praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
> >> können. Man stellt es als "korrekt" dar, und schon hört man überall "Du
> >> splltest Datensätze möglichst nicht sperren..." Kannst du das in solcher
> >> Allgemeinheit wirklich behaupten? Ich denke, nein.
> >
> > Doch, die Freiheit nehm ich mir.
> > Als ich beispielsweise in die Firma kam, wo ich zur Zeit arbeite, war
> > der DAL voll mit Locks, mittlerweile gibt es kein einziges Lock mehr.
> > Locks mögen einem in vielen Fällen das Leben einfacher machen, aber
> > sie sind einfach unschön und ich bin der Meinung, dass sie nicht
> > wirklich notwendig sind; irgendwie lässt es sich immer anders lösen.
>
> Hallo Daniel,
> genau das ist es, was ich meine. Warum sind Locks "einfach unschön"?
> Nenne mir Nachteile, aber vergleiche immer mit den Alternativen - IMHO
> sind die in der Regel noch nachteiliger. "Nicht wirklich notwendig"?
> Stimmt! Kann man alles auch anders machen - aber die grundsätzliche
> Frage bleibt: Ist es dann besser?
Wenn ich Lock setze ist meine Anwendung von diesem Moment an nur noch
für einen User voll funktionsfähig. Allein diese Tatsache genügt
mir, um mich dagegen zu entscheiden und einen höheren
Programmieraufwand in Kauf zu nehmen. Dazu kommt, dass sobald ich auch
nur an einer Stelle ein Lock setze fortan dieses Lock berücksichtigen
muss um nicht irgendwann in eine Deadlock Falle zu laufen. Kommt
irgendwann doch der gefürchtete Deadlock, dann viel Spass beim Finden
der Ursache. Spätestens dann macht sich optimistic locking bezahlt.
> In Eurer Firma scheint es möglich gewesen zu sein, auf Locking zu
> verzichten. Schön! Dann ist es gut, ohne zu arbeiten. Es ging in diesem
> Thread jedoch darum, ob optimistic locking *grundsätzlich* besser ist -
> und das bezweifle ich. Ich behaupte sogar, dass es in den meisten
> Desktop-Szenarien schlechter als Sperren ist.
Bei uns werden nur Web Anwendungen entwickelt, aber an der Art der
Anwendung kann ich nicht im geringsten festmachen, ob ich mit
optimistic oder pessimistic locking arbeite. Ob ich nun eine ASP.NET
oder eine Windows Forms Anwendung hab - beide können von greifen
verschiedenen Clients aus auf einen entfernten DB Server zugreifen, da
ist kein Unterschied. Rein theoretisch sollte ich den BLL und DAL einer
Webanwendung auch ohne Anpassungen in einer Wndows Forms Anwendung
nutzen können.
> > Ok, kurz vorm Abschicken ist mir noch ein Szenario eingefallen, wo ich
> > tatsächlich nicht drum herum gekommen bin, aber trotzdem: Locks so oft
> > wie möglich vermeiden. Wenn es anders geht, sollte man es auch anders
> > machen. (Bei meinem Fall geht es auch nicht um Benutzereingaben).
>
> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
> vermeiden sollte, und insbesondere interessiert mich, warum die
> Alternative besser ist.
Wie gesagt, "mal eben ein Lock setzen" macht das Leben des Entwicklers
entschieden einfacher. Beispiel warum man es trotzdem vermeiden sollte,
hab ich in der Antwort wo's um Buchungskraft A und B ging.
--
MfG,
Daniel Kuppitz
Paul Werkowitz
> Hallo Sascha,
>
> ? Nö... Stichwort "Optimistic Concurrency". Es gibt ja nun mehrere
> Ansätze wie man es umsetzen kann. Mein Favorit: der Timestamp.
>
[Beispiel snipped]
Ja ja, der Timestamp..... das Schweizer Messer der
Datenbankprogrammierer - kommt direkt nach der GUID-PK.
Löst das Problem, zumindest zum größten Teil. Man kann schnell
feststellen, ob jemand den Satz zwischenzeitlich geändert hat. Die Frage
aber bleibt: was dann tun? Wie hier z.B.:
> Schlussfolgerung: Datensatz wurde zwischenzeitlich bearbeitet.
> Reaktion: Auslesen des neuen Timestamp und Frage an Benutzer B, ob DS
> trotzdem gespeichert werden soll, evtl. Anzeige der aktuellen Daten.
nicht wirklich, oder?
[snip]
> Eine andere Möglichkeit wäre sich die Originalwerte, also die Werte
> zum Zeitpunkt des initialen Auslesens zu merken und dann ein Query in
> der Art abzuschicken:
jo, auch möglich. Löst wieder das Problem, wie man die Änderung
feststellen kann, und auch *was* hintenrum geändert wurde. Nur: was tun
in einem solchen Fall bleibt weiter offen...
Paule
Paul Werkowitz
> Hallo Sascha,
>
>
> Man legt z.B. fest, dass Datensätze ohne Zeitstempel oder solche mit
> einem Zeitstempel, der älter als 5 Minuten ist, als nicht gesperrt
> gelten.
Jo, wie schon gesagt: Der Zeitstempel - das Schweizer Messer der
Datenbankprogrammierung.
Bleibt noch die Frage: wie soll das Interval gewählt werden? Hier muss
eine Abwägung zwischen widersprechenden Zielen getroffen werden.
BTW, dieser Ansatz kommt unserer derzeit gewählten Lösung recht nahe:
wir verwenden Sperrdateien im Dateisystem. Der Dateiname codiert eine
Resource. Es gibt ein Flag (habe ich gerade vergessen, welches), das
bewirkt, dass die Datei vom Betriebssystem automatisch gelöscht wird,
wenn das ltzte Handle geschlossen wird (also insbesondere auch, wenn der
client gestorben ist). Man kann also in der Praxis davon ausgehen, dass
eine existierende Sperrdatei eine legitime Sperre bezeichnet.
Voraussetzung ist natürlich, dass alle clients Zugriff auf ein
gemeinsames Netz-Verzeichnis haben müssen, was evtl. nicht überall
möglich ist.
Grüße - Paule.
Daniel Kuppitz
> feststellen, ob jemand den Satz zwischenzeitlich geändert hat. Die Frage
> aber bleibt: was dann tun? Wie hier z.B.:
>
> > Schlussfolgerung: Datensatz wurde zwischenzeitlich bearbeitet.
> > Reaktion: Auslesen des neuen Timestamp und Frage an Benutzer B, ob DS
> > trotzdem gespeichert werden soll, evtl. Anzeige der aktuellen Daten.
>
> nicht wirklich, oder?
Oh doch. Du als Entwickler der Anwendung kannst dem Endbenutzer nicht
die Entscheidung abnehmen, was er in einem solchen Fall tun will. Der
beste Vergleich sind hier wirklich Versionsverwaltungssysteme. Ist ein
Konflikt nicht mehr auflösbar, muss der User selbst entscheiden und
das ist auch gut so, alles andere könnte fatale Folgen haben.
--
MfG,
Daniel Kuppitz
Peter Fleischer
...
> Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt man
> dann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
> auseinanderzudividieren.
Paul,
ich sehe da immer noch kein Problem, einen Zeitstempel für die Organisation
der Sperre zu nutzen. Peter Götz hat es doch genau beschrieben. Du hast nur
den Ablauf um ein paar wesentliche Details vereinfacht.
0. - Buchungskraft A und Buchungskraft B haben auf ihren Bildschirmen eine
Liste von Kunden, Die Kiste wurde irgenwann mal geladen. Ob da
zwischenzeitlich Änderungen vorgenommen wurden, kann die Buchungskraft nur
erkennen, wenn sie Aktualisieren aufruft (Refresh=Refill).
> 1. - Buchungskraft A ruft Kunde auf den Bildschirm,
Genau hier wird im Programm bei Buchungskraft A die Detialansicht
aufgerufen, die vom Server den aktuellen Datensatz haolt und mit Zeitstempel
sperrt.
> und korrigiert auf Grund von vorliegendem Beschwerdebrief die
> Rechnungsstellung. Z.B. sind nicht 63 Stunden, sondern in Wirklichkeit nur
> 36 Stunden gearbeitet worden. Einige weitere Änderungen sollen gemacht
> werden.
> 2. - In dieser Zeit ruft der Kunde bei Buchungskraft B an, und beschwert
> sich. B ruft Kunde auf den Bildschirm, und sieht,
Und genau hier sieht Buchungskraft B beim Aufruf der Detailansicht, dass der
Datensatz in Arbeit ist.
> dass irrtümlich 63 statt 36 Stunden notiert sind. B korrigiert dies,
Buchungskraft B kann das nicht korrigieren, das der Zeitstempel noch nicht
abgelaufen ist.
> redet eine Weile mit dem Kunden, macht vielleicht noch eine Notiz etc.
Genau die Notiz muss sich die Buchungskraft B machen, da sie nicht speichern
kann.
> 3. - Zwischenzeitlich ist A fertig und speichert den Satz.
Und der Zeitstempel wird gelöscht.
> 4. - Auch B beendet irgendwann das Gespräch, und möchte die vereinbarten
> Änderungen speichern.
Das geht aber nicht, da zum Zeitpunkt des Aufrufes der Datensatz mit einem
gültigen Zeitstempel belegt war. Bei bedarf kann natürlich über den
Notification Service die Buchungskraft B über das Löschen des Zeitstempels
informiert werden. Sie muss dann den Datensatz erneut aufrufen - damit wird
ein neuer Zeitstempel gesetzt - kann ihn anhand der Notizen bearbeiten, sie
die bereits ausgeführte Änderung und kann bei Notwenodigkeit abspeichern,
fall noch andere Änderungen gemacht wurden.
Ich weiß nicht, wo da ein Problem entstehen soll.
Peter
Paul Werkowitz
> Paul Werkowitz wrote:
> ...
>> Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt man
>> dann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
>> auseinanderzudividieren.
> ...
>
> Paul,
> ich sehe da immer noch kein Problem, einen Zeitstempel für die Organisation
> der Sperre zu nutzen. Peter Götz hat es doch genau beschrieben. Du hast nur
> den Ablauf um ein paar wesentliche Details vereinfacht.
Hallo Peter,
dies genau ist die Lösung mit Sperren. Du verwendest einen bestimmten
Mechanismus, um die Sperre zu implementieren, nämlich Zeitstempel in
einer zusätzlichen Spalte der Tabelle. Es *bleibt* jedoch eine
Sperrtechnik auf Recordebene.
*Ich* bin derjenige, der dieses pessimistic locking für gut hält. *Mich*
brauchst du nicht überzeugen.
Zur Erinnerung: Dieser Thread ging darum, dass ich gesagt habe, dass
optimistic locking nicht immer und überall angemessen sein könnte, und
dass die These "optimistic locking == immer richtig" eben nicht richtig ist.
>
> Ich weiß nicht, wo da ein Problem entstehen soll.
Ich auch nicht. Eben weil wir Sperren verwenden.
Grüße - Paul
Paul Werkowitz
> Hallo Paul,
[snip]
> Wie schon im letzten Beitrag erwähnt, finde ich es am elegantesten
> entsprechende Tabellen mit einer Timestamp Spalte zu versehen (so wird
> der Traffix auch nicht gleich nahezu verdoppelt). Die Kollision wird
> also anhand der Timestamp Spalte erkannt. So weit, so gut...
> Jetzt sind wir an dem Punkt, wo es zum Mehraufwand kommt. Eine schöne
> Lösung wäre es, den Eintrag aus der DB zu holen, alle Felder
> anzuzeigen und die Unterschiede bezogen auf den lokalen Stand
> hervorzuheben. Der Anwender kann dann entscheiden, ob er seine
> Änderungen verwirft, speichert oder noch einmal bearbeitet.
Jo, genau so müsste man es machen. Berücksichtigen sollte man den Fall,
dass während der Diff-Anzeige der Record erneut geändert wird, etc.
Ich stimme zu, dass man es so machen *kann* Der Aufwand ist aber nicht
unerheblich, und zwar nicht nur auf der Entwicklungsseite, sondern auch
beim Benutzer, der mit einemkomplett neuen Userinterface zurechtkommen
muss, was zudem ein seltener Fall ist.
Bei uns bevorzugen wir die Ding-Metapher: Wenn jeman was hat, dass hats
eben kein anderer. Wenn er es zurücklegt, kanns ein anderer nehmen.
Diese Betrachtungsweise kennen eigentlich alle aus dem täglichen Leben
und können damit umgehen. Das nur zum Thema "usability", weil weiter
unten angesprochen. IMHO können die Leute damit besser umgehen, als mit
einem post-Problem-Handling mit komplett anderem Benutzerinterface etc.
> Mehr Programmieraufwand = mehr Kosten für den Kunden. Aber die Praxis
> zeigt auch, das viele Kunden einwilligen, wenn man gute Argumente hat
> und das Argument an dieser Stelle wäre eindeutig die Usability. Ich
> wüsste nicht, welchen Anwender ein solches Verhalten der Anwendung
> überfordern soll.
Da die Kollision selten vorkommt, sind die Verfahren, wie dann zu
reagieren ist, unbekannt. Wir kriegen hier ständig Anrufe aus weit
weniger schwerwiegenden Gründen, meist weil die Leute nicht in der Lage
sind oder nicht wollen, in das Manual zu schauen.
> Mir als "Buchungskraft B" wäre es lieber, wenn ich den Datensatz
> erstmal bearbeiten kann, statt nicht zu wissen warum der Datensatz
> gesperrt ist, bzw. von wem er gerade bearbeitet wird.
Mir wahrscheinlich auch - ich bin aber SW-Entwickler, und kein
Belegmäuschen.
Außerdem: Man kann durchaus anzeigen, wie lange der Satz schon belegt
ist, und von wem. Wir führen sogar weitere Informationen wie z.B.
Username, Stationname, IP-Adresse etc. mit, um ein Nachrichtensystem zu
ermöglichen.
Die Frage nach dem "Warum" hatten wir hier noch nie: IdR. wollte einer
was bearbeiten.
>
>> Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt man
>> dann lieber Sperren in Kauf, als komplexe Probleme im Nachhinein
>> auseinanderzudividieren.
>
> Nur zu, bauen wir es solange aus, bis wir ein Deadlock Szenario haben
> und die "optimistische Seite" das Killerargument in der Hand hat ;-).
>
Die Deadlock-Problematik muss natürlich überlegt werden. Wir gingen hier
aber zunächst einmal von einem schlichten Record aus. Wenn allerdings
noch weitere Resourcen im Spiel sind, muss man aufpassen. Die einfachste
Methode ist, alle möglichen Resourcen geeignet durchzunummerieren und
immer in aufsteigender Reihenfolge aquirieren und umgekehrt wieder
freizugeben. Insbesondere bei 1:n oder m:n Beziehungen in der DB nicht
weiter schwierig.
> [1] http://www.codeproject.com/useritems/Diff_Patch_Utility_in_C_.asp
>
Link geht hier nicht. Vielleicht ist die site down, versuche es später
nochmal.
Grüße - Paule
Peter Götz
> >> das kommt immer drauf an. Optimistic Locking wird zwar immer
> >> grundsätzlich empfohlen
> >
> > Meist aus gutem Grund.
>
> Ich höre.
> 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.
> Wie gesagt, Webanwendungen sind eine andere Baustelle.
Ob Web- oder sonstige Anwendung, spielt erst mal keine Rolle, solange
mehrere Benutzer auf eine gemeinsame Datenbank zugreifen. Man kann
obiges Beispiel ja auch noch drastischer darstellen, wenn man eine
Tabelle mit 1000 Datensätzen und 500 ständig ändernden Benutzer nimmt.
Dann wäre ständig annähernd die Hälfte aller Datensätze gesperrt.
Flüssiges Arbeiten wäre in diesem Fall wohl kaum noch möglich.
> >> und hier auch immer schön nachgebetet,
> >> allerdings werden die Nachteile meist schöngeredet.
> >
> > Welche konkreten Nachteile?
>
> Grundsätzlich reduziert sich die Menge der Probleme und Nachteile auf
> folgende, hier vereinfacht dargestellte Überlegung:
>
> In einem Multi-User Szenario musst du damit rechnen, dass zwei user
was
> machen wollen, was potentiell die gleichen Ressourcen benötigt.
Ja, das liegt in der Natur der Sache, ist aber kein wirkliches Problem
und schon gar kein unlösbares.
> Beschränken wir uns hier also mal auf die Resourcen
"Datenbankrecords",
> die - mal angenommen - nicht von mehreren "gleichzeitig" verändert
> werden sollen.
Ein Datensatz kann schon aus technischen Gründen nicht wirklich
"gleichzeitig" von mehreren Benutzer verändert werden.
Definiere doch mal exakt dieses "gleichzeitig ändern".
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.
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. 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.
Eine ganz simpler Mehrbenutzerkonflikt und eine ebenso simple
Konfliktlösung.
>
> Während asynchrone Zugriffe auf solche Resourcen in der Informatik
> grundsätzlich mit Locking, Semaphoren oder ähnlichen Mechanismen
> serialisiert werden,
Warum sollte man bei dem oben geschilderten Szenario "grundsätzlich"
Datensätze vom Beginn der Änderungseingabe bis zum Ende der Ausführung
des Update-Commands sperren?
Wer glaubt, man müsse das "grundsätzlich" tun, hat nicht wirklich
verstanden, wie man sinnvoll und ökonomisch mit Datenbanken arbeitet.
> wollen dies viele Datenbankler besser wissen und
> verlangen die Möglichkeit, eine Resource unabhängig und wie im
> Singleuser-Betrieb verfügbar zu haben.
Ich weiss nicht recht, was Du mit "unabhängig wie im
Singleuser-Betrieb" meinst.
ADO.net, arbeitet grundsätzlich verbindungslos und mir ist bis heute
keine Problemstellung bekannt geworden, die sich mit dieser
Arbeitsweise nicht lösen liesse.
>
> Als Folge werden Mechanismen benötigt, um die parallel Benutzung
einer
> Resource (Hier: Veränderung eines Records) zu erkennen und eventuelle
> Komplikationen *nachträglich* zu behandeln.
Was ist besser,
a.) 10% aller Datensätze einer Tabelle als gesperrt zu kennzeichen
oder
b.) < 0,01 % weniger aller Datensätze der selben Tabelle zu
sperren?
> Empfohlen wird gerne, vor
> dem Speichern eines Satzes diesen *komplett* (!) nocheinmal zu lesen
und
> mit dem eigenen Originalstand (den man sich dann getrennt und
zusätzlich
> merken muss (!!))
Warum muss man sich den "getrennt und zusätzlich" merken?
Genügen die in den Datensätzen einer DataTable vorhandenen
OriginalValues nicht?
> zu vergleichen.
Wozu sollte denn das gut sein?
Das grenzt ja schon fast an groben Unfug.
Du würdest also vor dem Update erst noch mal den Datensatz einlesen,
prüfen, ob noch alles wie vorher ist und erst dann Deinen UpdateCommand
ausführen?
Und was machst Du, wenn zwischen Deinem nochmaligen Einlesen des
Datensatzes und dem Ausführen Deines UpdateCommands ein anderer
Benutzer den Datensatz wieder geändert hat?
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.
Eine Fehlererkennung und Fehlerbehandlung ist ohnehin erforderlich,
somit entsteht also so gut wie kein Mehraufwand.
> 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. In den weitaus weniger vorkommenden Fällen von
Mehrbenutzerkonflikt kann, muss aber nicht in jedem Fall zusätzlicher
Datenverkehr entstehen.
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.
> Während man dies noch durch ein paar zusätzliche Euronen, die man in
> einen stärkeren Server investiert, leicht in den Griff bekommt, wird
es
> bei der Überlegung, wie denn nach einer Kollisionserkennung zu
verfahren
> sei, schon schwieriger.
Was soll denn daran schwierig sein?
Ein Standardszenario, das in zigtausenden von DB-Anwendungen auf
einfachste Weise gelöst wird.
> Peter und/oder Daniel mögen mir zum Beispiel
> einmal erklären, was ich als Softwareentwickler in folgendem Szenario
> tun sollte:
>
> 1. - Buchungskraft A ruft Kunde auf den Bildschirm, und korrigiert
auf
> Grund von vorliegendem Beschwerdebrief die Rechnungsstellung. Z.B.
sind
> nicht 63 Stunden, sondern in Wirklichkeit nur 36 Stunden gearbeitet
> worden. Einige weitere Änderungen sollen gemacht werden.
Kein Problem Buchungskraft A gibt die entsprechende Korrektur ein und
speichert sie.
>
> 2. - In dieser Zeit ruft der Kunde bei Buchungskraft B an, und
beschwert
> sich. B ruft Kunde auf den Bildschirm, und sieht, dass irrtümlich 63
> statt 36 Stunden notiert sind.
Wenn Buchungskraft A schneller war, sieht Buchungskraft B, dass der
Fehler schon behoben ist und teilt dies dem Kunden mit.
Falls Buchungskraft B nicht ganz so schnell war ...
> B korrigiert dies, redet eine Weile mit
> dem Kunden, macht vielleicht noch eine Notiz etc.
>
> 3. - Zwischenzeitlich ist A fertig und speichert den Satz.
>
> 4. - Auch B beendet irgendwann das Gespräch, und möchte die
vereinbarten
> Änderungen speichern.
Da der Programmierer wusste, wie man auf simple Weise solche
Mehrbenutzerkonflikte löst, hat er den Updatecommand mit einer über
alle Felder gehenden, auf OriginalValues prüfenden Where-Klausel
ausgestattet und bekommt eine Fehlermeldung, die besagt, dass der
Datensatz bereits geändert worden ist.
> Was soll die Software jetzt tun? Es kann relativ problemlos erkannt
> werden, dass der Satz zwischenzeitlich geändert wurde. Man kann nun
den
> Satz nicht einfach neu laden
Warum kann man das nicht?
Noch dazu wo das, wie die Praxis zeigt, ja nur recht selten vorkommt.
> und von B verlangen
>
> - alles durchzulesen, um zu sehen, ob evtl. Teile oder alle
gewünschten
> Änderungen bereits von anderer Stelle durchgeführt wurden
>
> - das, was noch nicht drin ist, neu einzugeben. Denn: Der Kunde hat
> aufgelegt, und B hat sich keine Notizen gemacht, sondern
> selbstverständlich die Erkenntnisse aus dem Gespräch sofort in die
Maske
> eingetragen.
Kann dieser bemitleidenswerte Mitarbeiter nur von Notizblöcken lesen,
nicht aber seine eigenen Eingaben in einer Bildschirmmaske?
> Klar - es gibt auch hier Lösungsstrategien, z.B. die Differenzen zu
> bestimmen und diese gesondert anzuzeigen etc. IN der Praxis alles
> schwierig, da - mal abgesehen vom Programmieraufwand - viele Benutzer
> damit überfordert sind.
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.
> Dieses Szenario kann beliebig ausgebaut werden. IM Endeffekt nimmt
man
> dann 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?
Ich kann nur noch erstaunt mit dem Kopf schütteln.
> > Wieviele und welche konkrete Anwendungsfälle fallen Dir auf Anhieb
ein,
> > bei denen pessimistic Locking wirklich unumgänglich erforderlich
wäre?
> >
>
> Keine. Das war auch nicht das Thema.
Was war denn sonst das Thema?
Paul Werkowitz
>> Löst das Problem, zumindest zum größten Teil. Man kann schnell
>> feststellen, ob jemand den Satz zwischenzeitlich geändert hat. Die Frage
>> aber bleibt: was dann tun? Wie hier z.B.:
>>
>>> Schlussfolgerung: Datensatz wurde zwischenzeitlich bearbeitet.
>>> Reaktion: Auslesen des neuen Timestamp und Frage an Benutzer B, ob DS
>>> trotzdem gespeichert werden soll, evtl. Anzeige der aktuellen Daten.
>> nicht wirklich, oder?
>
> Oh doch. Du als Entwickler der Anwendung kannst dem Endbenutzer nicht
> die Entscheidung abnehmen, was er in einem solchen Fall tun will.
Eben genau deshalb wähle ich ein Design, in dem solche Sachen per
Definitionem ausgeschlossen sind.
> Der
> beste Vergleich sind hier wirklich Versionsverwaltungssysteme. Ist ein
> Konflikt nicht mehr auflösbar, muss der User selbst entscheiden und
> das ist auch gut so, alles andere könnte fatale Folgen haben.
>
Wie in meinen anderen Postings bereits erläutert, bedeutet das
erheblichen Aufwand auf der Entwicklungsseite sowie Lernaufwand bei den
USern. Da wir nicht immer die hellsten User haben und solche Konflikte
eher selten vorkommen, sehe ich voraus, dass die erst mal beim
Hersteller (also bei uns) anrufen, was das den nun wieder zu bedeuten
hat. Das nur zum Thema "Usability".
BTW Versionsverwaltungssysteme: Bis vor kurzem war es so, dass man dort
was zum Bearbeiten ausgecheckt hat, und dann war es für andere gesperrt.
VSS arbeitet noch heute so. Erst mit den Webanwendungen kamen lock-free
Szenarien auf den Markt, wie z.B. bei Subversion etc. Meist kann über
den 3-way-Merge alles automatisch aufgelöst werden, das geht aber nur
deshalb, weil wir meist Textdateien haben und dort
patternmatching-Algorithmen gut funktionieren (und weil die Leute meist
an unterschiedlichen Stellen der Datei arbeiten). Aber bereits bei
Make-Dateien z.B. geht das in der Praxis schon in die Hose. Ganz zu
schweigen von z.B. Projekt- oder Solutiondateien von VS. Da hast du dann
den alten Stand und den Neuen von Bearbeiter A und einen Neuen von
Bearbeiter B ..... welchen nimmst du dann?
>Ist ein
> Konflikt nicht mehr auflösbar, muss der User selbst entscheiden und
> das ist auch gut so, alles andere könnte fatale Folgen haben.
Erzähl' den beiden einfach, dass entweder A oder B seine Änderungen
verlieren wird, sofern nicht A oder B - oder du - schnell einen
Mergealgorithmus für Projektdsateien schreibt - Das ist ja das, was hier
immer vorgeschlagen wird: Diffs anzeigen und auswählen lassen.
Ehrlich gesagt..... da wäre mir exklusives Sperren lieber. Da muss ich
vielleicht bisschen warten, aber ich bin sicher, nichts zu verlieren.
Grüße - Paule
Peter Götz
> Ja ja, der Timestamp.....
Du verwechselst Timestamp-Feld mit einem Feld das leer ist oder einen
Wert vom Typ Date enthält.
> das Schweizer Messer der
> Datenbankprogrammierer - kommt direkt nach der GUID-PK.
>
> Löst das Problem, zumindest zum größten Teil. Man kann schnell
> feststellen, ob jemand den Satz zwischenzeitlich geändert hat.
Nein mit einem Date-Feld kann wird nicht festgestellt ob ein Datensatz
geändert worden ist, sondern dieses Feld signalisiert einfach nur, ob
der Datensatz gerade von einem Benutzer zur Bearbeitung reserviert
worden ist und deshalb nicht verändert werden darf.
> Die Frage
> aber bleibt: was dann tun?
Na was wohl?
Den Datensatz nicht verändern, sondern bestenfalls nur lesen.
> Wie hier z.B.:
>
> > Schlussfolgerung: Datensatz wurde zwischenzeitlich bearbeitet.
Falsche Schlussfolgerung.
Ob der Datensatz verändert oder nicht verändert ist, sagt ein Feld mit
Date nicht aus.
Dieses Feld wird zum Beginn einer Änderung mit der akt. Zeit + 5
Minuten beschrieben und signalisiert nun allen anderen Benutzern
lediglich dass dieser Datensatz bis zum Ablauf der im Zeitfeld
enthaltenen Zeit nicht verändert werden darf.
> > Reaktion: Auslesen des neuen Timestamp und Frage an Benutzer B, ob
DS
> > trotzdem gespeichert werden soll, evtl. Anzeige der aktuellen
Daten.
>
> nicht wirklich, oder?
Wenn ich das Ganze mal auf mein ursprüngliches Posting mit dem Zeitfeld
beziehe, dann scheinst Du das nicht wirklich verstanden zu haben. Das
wundert mich um so mehr, da Du Dich als erfahrenen DB-Programmierer
bezeichnest und offenbar noch nie was von diesem überall eingesetzten
Allerweltsverfahren gehört hast.
> [snip]
>
> > Eine andere Möglichkeit wäre sich die Originalwerte, also die Werte
> > zum Zeitpunkt des initialen Auslesens zu merken und dann ein Query
in
> > der Art abzuschicken:
>
> jo, auch möglich. Löst wieder das Problem, wie man die Änderung
> feststellen kann, und auch *was* hintenrum geändert wurde. Nur: was
tun
> in einem solchen Fall bleibt weiter offen...
Wenn ich z.b. via DataAdapter eine DataTable mit Daten aus einer
DB-Tabelle befülle, dann enthält sie erst mal die Originaldaten aus der
DB.
Nun kann ich an meiner lokalen DataTable einen oder mehrere Datensätze
ändern und verliere dabei dennoch nicht die noch immer in der DataTable
vorhandenen OriginalValues.
Und wie man beim Ausführen eines Update-Commands feststellen kann ob
der Datensatz zwischenzeitlich verändert worden ist, habe ich Dir ja
nun schon mehrfach erklärt (Stichwort Where-Klausel die alle Felder auf
OriginalValues prüft).
Wie man mit diesen OriginalValues verfahren kann, kannst Du Dir unter
www.gssg.de -> Visual Basic
-> VB.net -> DataTable / DataView, RowState
ansehen.
Peter Götz
> > Man legt z.B. fest, dass Datensätze ohne Zeitstempel oder solche
mit
> > einem Zeitstempel, der älter als 5 Minuten ist, als nicht gesperrt
> > gelten.
>
> Jo, wie schon gesagt: Der Zeitstempel - das Schweizer Messer der
> Datenbankprogrammierung.
>
> Bleibt noch die Frage: wie soll das Interval gewählt werden?
Ganz einfach:
Man stellt fest, wie lange ein durchschnittlich geübter Benutzer
braucht, die entsprechende Änderungsmaske auszufüllen, gibt noch einen
Puffer von ca. 10...20% hinzu und schon hat man eine recht
praxisgerechte Zeitspanne. Für die besonders langsamen Benutzer
verlängert man kurz vor Ablauf des Zeitintervals den Zeiteintrag
nochmal um ein weiteres Interval und das evtl. auch noch ein weiteres
mal. Wenn der Benutzer dann immer noch nicht auf den Speichern-Button
geklickt hat, ist er wohl eingeschlafen oder nach Hause gegangen. Man
(das Programm) beendet dann die Eingabe und verwirft die schon
eingegebenen Daten.
> Hier muss
> eine Abwägung zwischen widersprechenden Zielen getroffen werden.
Wer sollte da wem widersprechen?
>
> BTW, dieser Ansatz kommt unserer derzeit gewählten Lösung recht nahe:
> wir verwenden Sperrdateien im Dateisystem. Der Dateiname codiert eine
> Resource. Es gibt ein Flag (habe ich gerade vergessen, welches), das
> bewirkt, dass die Datei vom Betriebssystem automatisch gelöscht wird,
> wenn das ltzte Handle geschlossen wird (also insbesondere auch, wenn
der
> client gestorben ist).
Wo soll denn eine solche Datei gespeichert sein?
Wenn die z.B. auf einem Server liegt und irgendeiner der Clients stürzt
ab, dann wird diese Datei das niemals erfahren.
> Man kann also in der Praxis davon ausgehen, dass
> eine existierende Sperrdatei eine legitime Sperre bezeichnet.
Na ja, man kann auch seine 5 Brötchen vom Bäcker mit dem 20-Tonner
holen oder sich mit der Sense rasieren.
> Voraussetzung ist natürlich, dass alle clients Zugriff auf ein
> gemeinsames Netz-Verzeichnis haben müssen, was evtl. nicht überall
> möglich ist.
Warum sollte das, sofern es ein Netz (LAN) gibt, nicht möglich sein?
>
> Grüße - Paule.
Irgendwie versetzt Du mich immer mehr in arges Erstaunen.
Peter Götz
> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
> vermeiden sollte, und insbesondere interessiert mich, warum die
> Alternative besser ist.
Je mehr Benutzer über die gesamte Zeit ihrer Dateneingabe den
jeweiligen Datensatz sperrren, um so grösser wird die
Wahrscheinlichkeit, dass andere Benutzer, die den selben Datensatz
bearbeiten wollen, warten müssen, bis er endlich mal wieder freigegeben
wird. In dieser Zeit müssen sie immer wieder mal versuchen, auf diesen
Datensatz zuzugreifen um zu sehen, ob er immer noch gesperrt oder
vielleicht jetzt doch schon frei ist.
Wenn die Anwendung ein solches pessimistisches Sperren nicht unbedingt
erfordert, dann ist dieses pessimistisches Sperrverfahren absolut
kontraproduktiv.
Man muss schon sehr lange und sehr gründlich nachdenken, bis einem ein
konkreter Anwendungsfall einfällt, der solch pessimistische Sperren
wirklich unumgänglich notwendig macht. Ich habe Dich ja schon mal
gefragt, ob Dir auf Anhieb ein solcher Anwendungsfall einfällt. Die
Antwort darauf bist Du bisher schuldig geblieben.
Paul Werkowitz
Daniel Kuppitz schrieb:
> Hallo Paul,
>
> für einen User voll funktionsfähig.
Hallo Daniel,
IMHO haben wir unterschiedliche Auffassungen vom problem domain. *Ich*
möchte einfach nicht, dass B potentiell Änderungen macht, wenn dies A
gerade auch darf. Wenn diese Möglichkeit für die erstrebenswert ist,
dann musst du es zulassen und bei Kollisionen nachträglich was tun. Dies
ist sicher OK, aber ich wiederhole hier nochmal, warum es für uns nicht
so gut wäre:
- zusätzlicher Entwicklungsaufwand, dessen Ergebnis niemand wirklich schätzt
- Orobleme mit dem user interface beim unerfahrenen / einfach
strukturierten Benutzer.
>Allein diese Tatsache genügt
> mir, um mich dagegen zu entscheiden und einen höheren
> Programmieraufwand in Kauf zu nehmen. Dazu kommt, dass sobald ich auch
> nur an einer Stelle ein Lock setze fortan dieses Lock berücksichtigen
> muss um nicht irgendwann in eine Deadlock Falle zu laufen. Kommt
> irgendwann doch der gefürchtete Deadlock, dann viel Spass beim Finden
> der Ursache. Spätestens dann macht sich optimistic locking bezahlt.
Hmmm. Ein überlegenswertes Argument. Jedoch:
- Dadlocks können bei DB-Records/Tabellen recht einfach vermieden werden.
- Ich befürchte, dass eine Situation, di einen Deadlock auslösen würde,
auch mit optimistic locking eine Reihe von Problemen hervorbringt. Ich
habe das jetzt nicht wirklich zuende überlegt, ist nur eine Befürchtung.
>
>> In Eurer Firma scheint es möglich gewesen zu sein, auf Locking zu
>> verzichten. Schön! Dann ist es gut, ohne zu arbeiten. Es ging in diesem
>> Thread jedoch darum, ob optimistic locking *grundsätzlich* besser ist -
>> und das bezweifle ich. Ich behaupte sogar, dass es in den meisten
>> Desktop-Szenarien schlechter als Sperren ist.
>
> Bei uns werden nur Web Anwendungen entwickelt, aber an der Art der
> Anwendung kann ich nicht im geringsten festmachen, ob ich mit
> optimistic oder pessimistic locking arbeite. Ob ich nun eine ASP.NET
> oder eine Windows Forms Anwendung hab - beide können von greifen
> verschiedenen Clients aus auf einen entfernten DB Server zugreifen, da
> ist kein Unterschied. Rein theoretisch sollte ich den BLL und DAL einer
> Webanwendung auch ohne Anpassungen in einer Wndows Forms Anwendung
> nutzen können.
Nicht ganz. Webanwendungen arbeiten zustandslos, d.h. nach einem
request/response Zyklus gehts komplett von vorne los. Dort wäre es
schwierig, Sperren längere Zeit vernünftig zu halten. Bei
Desktop-Anwendungen ist das einfacher, da man eben stateful und nicht
stateless arbeitet.
>
>
>>> Ok, kurz vorm Abschicken ist mir noch ein Szenario eingefallen, wo ich
>>> tatsächlich nicht drum herum gekommen bin, aber trotzdem: Locks so oft
>>> wie möglich vermeiden. Wenn es anders geht, sollte man es auch anders
>>> machen. (Bei meinem Fall geht es auch nicht um Benutzereingaben).
>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>> vermeiden sollte, und insbesondere interessiert mich, warum die
>> Alternative besser ist.
>
> Wie gesagt, "mal eben ein Lock setzen" macht das Leben des Entwicklers
> entschieden einfacher. Beispiel warum man es trotzdem vermeiden sollte,
> hab ich in der Antwort wo's um Buchungskraft A und B ging.
>
Kann ich dort nur teilweise nachvollziehen. Die Arbeiten nach einer
Kollisionserkennung können auch für den Benutzer schwierig bis unmöglich
sein. Vom Entwicklungsaufwand mal ganz zu schweigen. Aber ich stimme zu,
dass es wohl auf die Betrachtungsweise etc. ankommt.
Grüße - Paule
Peter Götz
> > Paul,
> > ich sehe da immer noch kein Problem, einen Zeitstempel für die
Organisation
> > der Sperre zu nutzen. Peter Götz hat es doch genau beschrieben. Du
hast nur
> > den Ablauf um ein paar wesentliche Details vereinfacht.
>
> Hallo Peter,
> dies genau ist die Lösung mit Sperren. Du verwendest einen bestimmten
> Mechanismus, um die Sperre zu implementieren, nämlich Zeitstempel in
> einer zusätzlichen Spalte der Tabelle. Es *bleibt* jedoch eine
> Sperrtechnik auf Recordebene.
>
> *Ich* bin derjenige, der dieses pessimistic locking für gut hält.
*Mich*
> brauchst du nicht überzeugen.
Genau das ist eben Deine Missverständnis.
Dieses Sperrverfahren ist nicht per se gut, sondern in den meisten
Fällen ein völlig überflüssiges. Es gibt eben kaum Anwendungsfälle in
denen es wirklich unumgänglich notwendig ist einen Datensatz vom Beginn
des Editierens bis zum Ende des UpdateCommands zu sperren. Bei diesem
Verfahren ist ein Datensatz über einen vergleichsweise riesigen
Zeitraum (Sekunden bis Minuten) gesperrt und somit für andere Benutzer
nicht frei verfügbar.
Mit optimistischem Locking reduziert sich die tatsächliche Sperrzeit
für einen Datensatz auf wenige Millisekunden, was zweifelsfrei für
andere Benutzer weit weniger Beeinträchtigung bedeutet.
Es ist also sehr wohl sinnvoll, wo immer möglich, mit optimistischen
Sperren zu arbeiten und pessimistische Sperren auf die verschwindend
wenigen vorstellbaren Anwendungsszenarien zu begrenzen.
> Zur Erinnerung: Dieser Thread ging darum, dass ich gesagt habe, dass
> optimistic locking nicht immer und überall angemessen sein könnte,
und
> dass die These "optimistic locking == immer richtig" eben nicht
richtig ist.
In 99,9% aller mir bekannten Fälle sind optimistische Sperren völlig
ausreichend.
Paul Werkowitz
blogs.msdn.com/queryoptteam/archive/2006/08/01/685659.aspx
auch nicht so recht erkennen, was dies mit unserem Thema hier zu tun
hat. Soweit ich das verstanden habe, geht es beim key range locking
immer um mehrere Records. Außerdem scheint mir die Frage eher für die
korrekte und effiziente Implementierung von Transactions wichtig zu
sein, nicht so sehr für den Anwendungsprogrammierer.
> Deine Argumentation deutet auf
> einige Unkenntnis hin, was das Thema angeht.
Schon möglich. Ich gehe allerdings mal davon aus, dass 90% aller aktiven
Programmierer die Aussagen des Papiers nicht kennen, und behaupte
weiter, dass nur wenige sie überhaupt verstehen. Insofern leben die
allermeisten hier wohl in Unkenntnis. Weiterhin gebe ich hiermit der
Hoffnung Ausdruck, es auch nicht kennen zu müssen, um gut programmieren
zu können.
Was bleibt, ist immer noch die von mir gestellte Frage aus dem letzten
Posting:
>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>> vermeiden sollte, und insbesondere interessiert mich, warum die
>> Alternative besser ist.
Also, bring mal ein konkretes Szenario und lass die Dogmatik weg.
Grüße - Paule
Peter Götz
> Ehrlich gesagt..... da wäre mir exklusives Sperren lieber. Da muss
ich
> vielleicht bisschen warten, aber ich bin sicher, nichts zu verlieren.
In einem grossen Unternehmen sollen also beispielsweise einige tausend
Mitarbeiter einen grossen Teil ihrer Arbeitszeit damit verbringen auf
das Freiwerden eines zu bearbeitenden Datensatzes zu warten?
Wer soll das bezahlen, wer hat soviel Geld, wer ....?
Daniel Kuppitz
> > Ja ja, der Timestamp.....
>
> Du verwechselst Timestamp-Feld mit einem Feld das leer ist oder einen
> Wert vom Typ Date enthält.
> ...
> Dieses Feld wird zum Beginn einer Änderung mit der akt. Zeit + 5
> Minuten beschrieben und signalisiert nun allen anderen Benutzern
> lediglich dass dieser Datensatz bis zum Ablauf der im Zeitfeld
> enthaltenen Zeit nicht verändert werden darf.
Sehr schön, wie viele Auffassungen davon, was eine Timestamp-Spalte
ist, gibt es hier eigentlich? Ein Timestamp ist kein Datumsfeld (schon
ewig nicht mehr). Ein Timestamp ist auch keine Zeit auf die ich 5
Minuten oder sonstwas drauf schlage.
Ein Timestamp wir vom Server automatisch bei jedem Update und Insert
geschrieben und repräsentiert die interene Serverzeit, die rein gar
nichts mit irgendeiner Uhrzeit oder ähnlichem zu tun hat. Siehe dazu
auch:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ta-tz_6fn4.asp
> > Löst das Problem, zumindest zum größten Teil. Man kann schnell
> > feststellen, ob jemand den Satz zwischenzeitlich geändert hat.
>
> Nein mit einem Date-Feld kann wird nicht festgestellt ob ein Datensatz
> geändert worden ist, sondern dieses Feld signalisiert einfach nur, ob
> der Datensatz gerade von einem Benutzer zur Bearbeitung reserviert
> worden ist und deshalb nicht verändert werden darf.
> ...
> Ob der Datensatz verändert oder nicht verändert ist, sagt ein Feld mit
> Date nicht aus.
Wie gesagt, es ist kein "Date-Feld". Signalisieren kann dieses Feld gar
nichts. Genau wie Paul sagt, kann ich damit nur feststellen, ob ein
Datensatz zwischenzeitlich geändert wurde - nämlich dann, wenn der
Wert des Timestamp nicht mehr der Wert ist, den ich anfangs ausgelesen
hab.
--
MfG,
Daniel Kuppitz
Peter Fleischer
...
>>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>>> vermeiden sollte, und insbesondere interessiert mich, warum die
>>> Alternative besser ist.
>
Paul,
pessimistic locking benötigt viel mehr Ressourcen und kann bei intensiver
Mehrnutzer-Tätigkeit zu Blockierungen führen.
Ein typisches Beispiel ist die Neuanlage von Stammdaten bei tiefer
Arbeitsteilung in einem Betrieb. Bearbeiter A erfasst den ersten Teil des
Stammdatensatzes, legt ihn an und bearbeitet ihn weiter; Bearbeiter B muss
den Datensatz ergänzen. Bearbeiter B muss bei pessimistischer Sperre warten,
bis Bearbeiter A den ihm zugewiesenen Informationsteil bearbeitet hat. Das
kann mit Recherchen, Rückfragen usw. verbunden sein und beträchtlich Zeit in
Aspruch nehmen. Bearbeiter B muss beispielsweise das Kreditorenkonto
eintragen, was er bei pessimistischer Sperre nicht kann. Man könnte
natürlich den Stammdatensatz so trennen, dass er nicht den Prinzipien der
Normalisierung entspricht, sondern den Orgabläufen im Unternehmen. Wenn dann
die Orgabläufe im Unternehmen geändert werden, muss auch die
Datenbankstruktur geändert werden. Ein Horrorszenario:-(
Peter
Peter Götz
> Sehr schön, wie viele Auffassungen davon, was eine
> Timestamp-Spalte ist, gibt es hier eigentlich?
Keine Ahnung, wieviele Leute welche Meinung über irgendwas haben.
Ich habe Paul lediglich darauf hingewiesen, dass ein Feld mit einem
Zeiteintrag, das einen Datensatz als "in Bearbeitung" kennzeichnet
nicht zu verwechseln ist mit einem TimeStamp-Feld wie es z.B. der
SQL-Server kennt.
> Ein Timestamp ist kein Datumsfeld (schon ewig nicht mehr).
> Ein Timestamp ist auch keine Zeit auf die ich 5
> Minuten oder sonstwas drauf schlage.
Du solltest meine Posting vielleicht erst mal lesen und wenns geht auch
verstehen und dann überlegen, ob Du Dinge kritisieren willst, die ich
so gar nicht geschrieben habe.
.... schnipp....
> Wie gesagt, es ist kein "Date-Feld". Signalisieren kann dieses Feld
> gar nichts. Genau wie Paul sagt,
Der offenbar meine Postings auch nicht gelesen oder zumindest nicht
wirklich verstanden hat.
> kann ich damit nur feststellen, ob ein Datensatz zwischenzeitlich
> geändert wurde - nämlich dann, wenn der Wert des Timestamp
> nicht mehr der Wert ist, den ich anfangs ausgelesen hab.
s.oben:
Ich habe nirgendwo etwas von einem TimeStamp-Feld geschrieben, sondern
von einem Feld im Datensatz, in dem man einen Wert vom Typ Date
einträgt. Beim beschriebenen Sperrverfahren eben einfach die Zeit Now()
+ ein bestimmtes Intervall von x Sekunden oder Minuten.
Daniel Kuppitz
> Ich habe nirgendwo etwas von einem TimeStamp-Feld geschrieben, sondern
> von einem Feld im Datensatz, in dem man einen Wert vom Typ Date
> einträgt. Beim beschriebenen Sperrverfahren eben einfach die Zeit Now()
> + ein bestimmtes Intervall von x Sekunden oder Minuten.
Bleiben Sie ruhig, ich hole Hilfe.......
Zitat [Peter Götz, Sun, Sep 3 2006 2:20 pm]:
"Du verwechselst Timestamp-Feld mit einem Feld das leer ist oder einen
Wert vom Typ Date enthält."
Hier hast Du schonmal was über's Timestamp Feld geschrieben.
Verwechselt wurde in diesem Fall nichts, denn es geht in diesem Zweig
der Diskussion um DEN Timestamp des SQL Server.
> Ich habe Paul lediglich darauf hingewiesen, dass ein Feld mit einem
> Zeiteintrag, das einen Datensatz als "in Bearbeitung" kennzeichnet
> nicht zu verwechseln ist mit einem TimeStamp-Feld wie es z.B. der
> SQL-Server kennt.
Meinetwegen. Diese Aussage trifft aber nicht auf das anfangs von mir
genannte Timestamp Feld zu und auf dieses beziehst Du Deine Aussage.
> Du solltest meine Posting vielleicht erst mal lesen und wenns geht auch
> verstehen und dann überlegen, ob Du Dinge kritisieren willst, die ich
> so gar nicht geschrieben habe.
Keine Angst, ich les die Postings. Du solltest aber vielleicht drauf
achten, in welchem Diskussionszweig Du Dich auf was beziehst. Wenn es
um eine Timestamp Spalte geht, dann geht es um eine Timestamp Spalte.
Dann brauch keiner kommen und sagen, dass es nicht um einen Timestamp,
sondern um ein Datumsfeld geht.
Das ganze ging los in meiner Antwort an Sascha. Ich habe dort ein
Szenario in den Raum gestellt, aus dem der Typ der Timestamp Spalte
eigentlich eindeutig hervor geht.
So, wie oft kommt in dem Posting jetzt "Timestamp" vor? :-) Jetzt
müssten sogar die Google Ads merken um was es eigentlich geht...
--
MfG,
Daniel Kuppitz
Peter Götz
> Zitat [Peter Götz, Sun, Sep 3 2006 2:20 pm]:
> "Du verwechselst Timestamp-Feld mit einem Feld das leer ist
> oder einen Wert vom Typ Date enthält."
> Hier hast Du schonmal was über's Timestamp Feld geschrieben.
Ja, eben dass man TimeStamp nicht mit dem Zeitfeld, welches ich in dem
von mir beschriebenen Sperrverfahren erwähnt habe, verwechseln sollte.
> Verwechselt wurde in diesem Fall nichts, denn es geht in diesem
> Zweig der Diskussion um DEN Timestamp des SQL Server.
Nein, um diesen geht es eben nicht.
Lediglich Paul hat wohl meine Beschreibung des Sperrverfahrens mit dem
Zeitfeld nicht wirklich verstanden und deshalb irrtümlich auf ein
Timestamp-Feld verwiesen.
Elmar Boye
Paul Werkowitz <newsg...@primaprogramm.de> schrieb ...
> Elmar Boye schrieb:
>> Paul Werkowitz <newsg...@primaprogramm.de> schrieb ...
>>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>>> vermeiden sollte, und insbesondere interessiert mich, warum die
>>> Alternative besser ist.
>>
>> Bitte informiere Dich erstmal was ein Sperre so alles anstellen kann,
>> was die Skalierbarkeit einer Anwendung angeht:
>
>> Denn nimms mir nicht übel: Deine Argumentation deutet auf
>> einige Unkenntnis hin, was das Thema angeht.
>>
> Nin, nehme ich dir nicht übel. Ich kann allerdings in dem Link
> blogs.msdn.com/queryoptteam/archive/2006/08/01/685659.aspx
> auch nicht so recht erkennen, was dies mit unserem Thema hier zu tun
> hat.
Dann fangen wir weniger abstrakt an:
http://msdn2.microsoft.com/de-de/library/ms190612.aspx
Transaktionen (Datenbankmodul)
und http://msdn2.microsoft.com/de-de/library/ms190615.aspx
"Sperren im Datenbankmodul "
> Soweit ich das verstanden habe, geht es beim key range locking
> immer um mehrere Records.
Nein, sie sind die Grundlage für die Isolationstufe Serializable -
u. a. Transaktionsmonitoren die Standardeinstellung.
Und jede niedrigere Isolationsstufe wie Read Committed ist
geht letztendlich einen Kompromiss (sprich Risiko) ein.
> Außerdem scheint mir die Frage eher für die korrekte und effiziente
> Implementierung von Transactions wichtig zu
> sein, nicht so sehr für den Anwendungsprogrammierer.
Wer einen Anwendungsprogrammier im Datenbankbereich Geld
bezahlt, der sich nicht mit Transaktionen auskennt, der ist selber schuld.
Denn ohne Kenntnis davon landet jede Anwendung über kurz oder
lang, was Daniel so schön beschrieben hat, mit:
>> Nur zu, bauen wir es solange aus, bis wir ein Deadlock Szenario haben
>> und die "optimistische Seite" das Killerargument in der Hand hat ;-).
> Was bleibt, ist immer noch die von mir gestellte Frage aus dem letzten
> Posting:
>
>>> "So oft wie möglich vermeiden" Warum eigentlich?
Die ganz kurze Fassung: Ein heutiges Datenbanksystem hat u. U.
eine Leistung von einigen Millionen TPC, zum Vergleich:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
(und auch kleinere bezahlbarere Systeme schaffen einige Zigtausend)
Wohingegen die Geschwindigkeit von Benutzern in den
kaum über eine oder zwei pro Sekunde hinauskommt ;-)
Greifen wir Dein Buchungsbeispiel auf, und vergessen wir sowohl
die Seltenheit ihres praktischen Vorkommens wie die Implementierungs-
schwächen (die Software sollte eine Verbuchung eines Vorgangs direkt
anzeigen):
Ein System kommt so sehr früh schnell an eine - letztendlich
unnatürliche - Leistungsgrenze.
Zumal es in der Praxis nicht bei einem isolierten "Record" bleibt:
Da will ein Lager, ein OP Eintrag, die eine oder andere Statistik
gebucht werden und diverses anders mehr. Was auch die von
Peter Götz bereits angeführten logischen Sperren in realen
Szenarien sehr komplex in der Umsetzung machen kann.
Und nicht zuletzt: Eher wenige RDBMS unterstützten überhaupt
pessimistische Konkurrenz - der SQL Server ist da aus Tradition
gut bestückt (weil man mal DBase III ablösen wollte).
Und IMHO widersprichst Du Dich schon mit der Aussage:
>>> Eigentlich ein guter Trick: Webanwendungen sind zustandslos, daher kommt
>>> praktisch nur optimistic locking in Frage, um überhaupt arbeiten zu
>>> können.
Immer mehr Systeme können beides. Und warum sollen die
unterschiedlich funktionieren?
Und real existierende Systeme - neben dem .NET DataSet die
meisten O/R Mapper (NHibernate uvm.) optimistisch arbeiten.
Und weil alles Geld kostet: Der oben von Dir zitierte "uninteressierte"
Anwendungsprogrammierer nutzt die Schnittstellen so wie sie
kommen und fragt sich wenns knallt in SQL Server Programming
und ähnlichen NGs/Foren durch.
Nur weil früherere Microsoft Schnittstellen wie ADODB anfangs mit
serverseitiger Programmierung geliefert und die clientseitige
Programmierung erst nachgereicht wurde, hat sich bei vielen
DB-Programmierern ein Mythos gehalten. Am stärksten denen
die Access als Anfangsdatenbank nutzten -> und sich schon
wundern, dass Access via ODBC optimistisch arbeitet.
Wobei das oben erwähnte O/R Mapping mit ehedem LINQ
(http://msdn.microsoft.com/data/ref/linq/)
jetzt ADO Entity Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/ADONETEnFrmOvw.asp
ebenfalls bei Microsoft Einzug hält.
Und damit das pessimistische Sperrmodell Microsoft-offiziell zum
Auslaufmodell wird, das es schon lange war.
> Also, bring mal ein konkretes Szenario und lass die Dogmatik weg.
Dogmatik ist das nicht - nur ca. 20 Jahre Datenbankprogrammierung (im
weitesten Sinne). Und der dabei etliche Male gemachten Erfahrung, dass
Gesprächspartner die Grundsätze verstanden haben müssen, ansonsten
redet man wie hier im Thread, in der Regel aneinander vorbei.
Gruss
Elmar
Klaus P. Pieper
Peter Götz schrieb:
>
> In 99,9% aller mir bekannten Fälle sind optimistische Sperren völlig
> ausreichend.
stimmt, ausreichend sind sie schon. Bei vielen klassischen
Desktop-Anwendungen kann man sowohl mit optimistischen als auch mit
pessimistischen Sperren arbeiten.
Das eigentliche Problem ist, dass der Programmieraufwand bei
optimistischen Sperren deutlich höher ist. Wir haben gerade unsere erste
Musteranwendung komplett auf optimistische Sperren umgestellt. Der
Aufwand gegenüber klassischem Record-Locking ist (geschätzt) doppelt so
hoch und bringt dem Benutzer keinerlei Vorteile.
Wenn ein Benutzer einen Beleg bearbeitet und ein anderer Benutzer will
den gleichen Beleg bearbeiten, *muss* der zweite Benutzer *bei Beginn
seines Vorgangs* darüber informiert werden, dass der Beleg gerade
gesperrt ist.
Der gesamte Ansatz mit dem "optimistic locking" ist für mich (zumindest
bei Forms-Anwendungen) der größte Rückschrift im .NET Framework
gegenüber den früheren Methoden.
AFAIR war ja zumindest beim Compact Framework 2.0 auch ein Locking
Mechanismus vorgesehen, der aber leider nicht realisiert wurde.
Wie Peter Werkowitz schon schrieb, mag die ganze Sache bei zustandslosen
Webanwendungen ganz anders aussehen, da man hierbei den ganzen Aufwand
mit Zeitstempeln oder ähnlichen Lösungen sowieso treiben muss.
Gruß
Klaus
--
reply pub . pieper ibeq
to kp3 . at . com
Klaus P. Pieper
Peter Götz schrieb:
> Hallo Paul,
>
>>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.
hier liegt wohl der Grund für die unterschiedlichen Ansätze. In meinem
Fall (und möglicherweise auch bei einigen anderen Leuten) habe ich es
meistens mit größeren Tabellen zu tun (deutlich über 10.000 Datensätze),
dafür aber nur mit einigen Benutzern. Als Größenordnung zwischen 5 und
50. Der Anteil der gesperrten Datensätze ist also viel kleiner als von
dir angenommen.
>
> Ob Web- oder sonstige Anwendung, spielt erst mal keine Rolle, solange
> mehrere Benutzer auf eine gemeinsame Datenbank zugreifen. Man kann
> obiges Beispiel ja auch noch drastischer darstellen, wenn man eine
> Tabelle mit 1000 Datensätzen und 500 ständig ändernden Benutzer nimmt.
> Dann wäre ständig annähernd die Hälfte aller Datensätze gesperrt.
> Flüssiges Arbeiten wäre in diesem Fall wohl kaum noch möglich.
Dieses Beispiel ist kein solches. Egal ob optimistisches oder
pessimistisches Locking - bei 1000 Datensätzen und 500 ständig
*ändernden* Benutzern ist das Chaos so oder so vorprogrammiert. Bei 1000
datensätzen sind sowieso nur wenige Änderungen pro Zeiteinheit möglich,
Lesezugriffe auf den Datenstand vor der Bearbeitung muss jedoch möglich
sein.
>
>>Beschränken wir uns hier also mal auf die Resourcen
>
> "Datenbankrecords",
>
>>die - mal angenommen - nicht von mehreren "gleichzeitig" verändert
>>werden sollen.
>
>
> Ein Datensatz kann schon aus technischen Gründen nicht wirklich
> "gleichzeitig" von mehreren Benutzer verändert werden.
> Definiere doch mal exakt dieses "gleichzeitig ändern".
Mit "gleichzeitig ändern" ist vermutlich gemeint, dass ein Datensatz
z.B. auf zwei Stationen zur gleichen Zeit zur Bearbeitung geöffnet ist.
Sicher ist hier jedem klar, dass Datensatzänderungen mehrerer Benutzer
immer sequentiell ablaufen.
>
> 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.
> 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. 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.
>
> Eine ganz simpler Mehrbenutzerkonflikt und eine ebenso simple
> Konfliktlösung.
Stimmt, ein ganz normaler Konflikt mit einer aufwändigen Lösung. Ein
Konflikt, den man zahlender Kundschaft genau einmal zumuten darf. Wenn
dieses Verhalten nicht schnellstens abgestellt wird, sieht sich der
Kunde nach einam anderen Produkt um. Seine Zeit ist nämlich teuer. Und
entweder Müller oder Schulze hat gerade seine wertvolle Arbeitszeit mit
Sozialabgaben und allem was dazu gehört "zum Fenster hinausgeworfen".
Selbst bei simplen dateibasierten Produkten wie bei einer
Textverarbeitung wird Schulze darauf hingewiesen, dass die Datei gerade
von Müller bearbeitet wird.
>
>>Während asynchrone Zugriffe auf solche Resourcen in der Informatik
>>grundsätzlich mit Locking, Semaphoren oder ähnlichen Mechanismen
>>serialisiert werden,
>
> Warum sollte man bei dem oben geschilderten Szenario "grundsätzlich"
> Datensätze vom Beginn der Änderungseingabe bis zum Ende der Ausführung
> des Update-Commands sperren?
> Wer glaubt, man müsse das "grundsätzlich" tun, hat nicht wirklich
> verstanden, wie man sinnvoll und ökonomisch mit Datenbanken arbeitet.
Vielleicht liegt auch hier ein Missverständnis vor. "Pessimistische
Sperre" heißt ja nicht unbedingt, dass Schulze nichts machen kann,
solange Müller den Datensatz geöffnet hält und in der Mittagspause ist.
Es sollte so sein, dass Schulze darauf hingewiesen wird, dass Müller den
Datensatz bearbeitet. Dann kann Schulze entweder einen anderen Vorgang
bearbeiten oder man kann sich darüber klar werden, warum ein Datensatz
zur gleichen Zeit bei beiden zur Bearbeitung anliegt. Das ist aber ein
organisatorisches Problem, keins der EDV.
>
> Was ist besser,
>
> a.) 10% aller Datensätze einer Tabelle als gesperrt zu kennzeichen
>
> oder
>
> b.) < 0,01 % weniger aller Datensätze der selben Tabelle zu
> sperren?
Da gibt es kein "besser" oder "schlechter". Das hängt immer vom
konkreten Anwedungsfall ab.
Klaus P. Pieper
Daniel Kuppitz schrieb:
>
> ? Nö... Stichwort "Optimistic Concurrency". Es gibt ja nun mehrere
> Ansätze wie man es umsetzen kann. Mein Favorit: der Timestamp.
... der letztendlich auch nichts anderes macht als eine pessimistische
Sperre: es wird signalisiert, dass der betreffende Datensatz gerade in
Bearbeitung ist.
Nur dass der ganze Mechanismus zur Auswertung dieses "Signals" jetzt in
die Anwendung verlagert wird und jeder Programmierer das Thema etwas
anders angeht, wo Spezialisten entsprechende Routinen im Server
implementiert und optimiert haben. Das ist wohl das beste Beispiel für
"das Rad neu erfinden". Wo ist hier der Fortschritt?
Klaus P. Pieper
Peter Götz schrieb:
>
> In einem grossen Unternehmen sollen also beispielsweise einige tausend
> Mitarbeiter einen grossen Teil ihrer Arbeitszeit damit verbringen auf
> das Freiwerden eines zu bearbeitenden Datensatzes zu warten?
1) es gibt nicht nur große Unternehmen mit einigen tausend Mitarbeitern
2) auch in großen Unternehmen können die Leute schon einmal etwas
anderes tun, solange ein Datensatz in Bearbeitung ist.
Stell dir doch einfach einmal ein großes Unternehmen mit Maschinen vor.
Solange eine Maschine mit dem Artikel A belegt ist, kann sie eben für
Artikel B nicht eingerichtet werden. Die Mitarbeiter wissen das und
organisieren sich entsprechend. Vereinfacht dargestellt suchen sie sich
eine freie Maschine, für die auch Aufträge vorliegen.
Klaus P. Pieper
Peter Götz schrieb:
> Die Zeit von 5 Minuten und die Anzahl der möglichen Verlängerungen ist
> entsprechend der jeweiligen Anwendungsgegebenheiten frei wählbar.
> Neben einem Rechnerabsturz könnte auch noch der Fall eintreten, dass
> ein Benutzer eine Änderung beginnt und dann telefoniert und telefoniert
> und telefoniert und ......
> Auch das ist kein Problem. Nach Ablauf der 5 Minuten bzw. nach Ablauf
> der möglichen Verlängerungszeiten beendet das Programm die Eingabe,
> verwirft die bisher vorgenommenen Eingaben, löscht den Zeitstempel und
> weist den Benutzer per Dialogbox darauf hin, dass er den Datensatz zu
> lange blockiert hat und nochmal von vorne beginnen muss.
deine Anwender möchte ich haben ... Was meinst du, was passiert, wenn
bei x € Stundensatz die Eingabe automatisch verworfen wird, nur weil ein
Telefongespräch dazwischen kam? Und wenn das immer wieder passiert?
Also muss man in der Anwendung auf das drohenden Timeout auch noch
aufpassen und zumindest abfragen, ob der Datensatz weiter bearbeitet
werden soll.
Klaus P. Pieper
Peter Fleischer schrieb:
> Paul,
> pessimistic locking benötigt viel mehr Ressourcen und kann bei intensiver
> Mehrnutzer-Tätigkeit zu Blockierungen führen.
>
> Ein typisches Beispiel ist die Neuanlage von Stammdaten bei tiefer
> Arbeitsteilung in einem Betrieb. Bearbeiter A erfasst den ersten Teil des
> Stammdatensatzes, legt ihn an und bearbeitet ihn weiter; Bearbeiter B muss
> den Datensatz ergänzen. Bearbeiter B muss bei pessimistischer Sperre warten,
> bis Bearbeiter A den ihm zugewiesenen Informationsteil bearbeitet hat. Das
> kann mit Recherchen, Rückfragen usw. verbunden sein und beträchtlich Zeit in
> Aspruch nehmen. Bearbeiter B muss beispielsweise das Kreditorenkonto
> eintragen, was er bei pessimistischer Sperre nicht kann. Man könnte
> natürlich den Stammdatensatz so trennen, dass er nicht den Prinzipien der
> Normalisierung entspricht, sondern den Orgabläufen im Unternehmen. Wenn dann
> die Orgabläufe im Unternehmen geändert werden, muss auch die
> Datenbankstruktur geändert werden. Ein Horrorszenario:-(
ich gebe dir Recht, was dieses Szenario angeht. Aber wie du schon
schriebst "kann bei intensiver Mehrnutzer-Tätigkeit zu Blockierungen
führen". Es geht hier also um einen Fall, der gar nicht allzu speziell
ist & auch sicherlich seine Berechtigung hat. Aber es gibt eben auch
andere Fälle, bei denen kein "intensiver Mehrbenutzerbetrieb" vorliegt,
die Zusammenarbeit aber trotzdem auch EDV-technisch koordiniert werden
muss.
Peter Götz
> Das eigentliche Problem ist, dass der Programmieraufwand bei
> optimistischen Sperren deutlich höher ist.
Was ist besser,
ein klein wenig mehr Programmcode oder ein beachtlich höherer
Ressourcenverbrauch auf dem LAN und beim Server und eine messbar
geringere Performance des gesamten Systems?
> Wir haben gerade unsere erste
> Musteranwendung komplett auf optimistische Sperren umgestellt. Der
> Aufwand gegenüber klassischem Record-Locking ist (geschätzt) doppelt
so
> hoch und bringt dem Benutzer keinerlei Vorteile.
Also das "doppelt so hoch" würde ich aber schon mal genauer
hinterfragen.
> Wenn ein Benutzer einen Beleg bearbeitet und ein anderer Benutzer
will
> den gleichen Beleg bearbeiten, *muss* der zweite Benutzer *bei Beginn
> seines Vorgangs* darüber informiert werden, dass der Beleg gerade
> gesperrt ist.
Und genau diese Forderung sollte man mal genau überprüfen.
Muss der Benutzer wirklich schon zu Beginn seiner Bearbeitung wissen,
dass ein anderer Benutzer auch an diesem Datensatz arbeitet?
Das trifft bestenfalls dann zu, wenn die vorzunehmende Änderung die
Kenntnis des bisherigen (momentanen) Datenzustandes unumgänglich
notwendig macht.
Überlege mal gründlich, wann das wirklich der Fall ist.
Trifft dies in sehr seltenen Fällen wirklich zu, lohnt es sich auch da
noch, zu überlegen, ob diese Situation durch ein geschickteres
Programmdesign nicht vermieden werden kann.
In ca. 99% der Fälle wird es ohnehin so sein, dass der Datensatz
tatsächlich gerade von keinem anderen Benutzer bearbeitet wird
(vorausgesetzt es werden nicht viele Datensätze unnötig lange durch
pessimistische Sperren blockiert) und somit ohnehin kein akutes
Mehrbenutzerproblem besteht.
Das verbleibende 1% lässt sich mit sehr wohl überschaubarem
Programmieraufwand und ohne sonderliche Schwierigkeiten abarbeiten.
> Der gesamte Ansatz mit dem "optimistic locking" ist für mich
(zumindest
> bei Forms-Anwendungen) der größte Rückschrift im .NET Framework
> gegenüber den früheren Methoden.
Das klingt ein wenig nach:
"Das haben wir schon immer so gemacht, warum sollen wir es jetzt anders
machen?"
Ich sehe beim verbindungslosen Betrieb wie ihn ADO ermöglicht und
ADO.net erzwingt eigentlich nur Vorteile. Auf diese Vorteile möchte ich
nicht verzichten, nur weil ich vielleicht alle 100 Jahre mal die
Notwendigkeit habe, einen Datensatz etwas länger zu sperren und dafür
ein paar Zeilen Code schreiben muss.
> AFAIR war ja zumindest beim Compact Framework 2.0 auch ein Locking
> Mechanismus vorgesehen, der aber leider nicht realisiert wurde.
Ich vermisse das absolut nicht.
> Wie Peter Werkowitz schon schrieb, mag die ganze Sache bei
zustandslosen
> Webanwendungen ganz anders aussehen, da man hierbei den ganzen
Aufwand
> mit Zeitstempeln oder ähnlichen Lösungen sowieso treiben muss.
Es spielt überhaupt keine Rolle ob man es für eine Web-Anwendung, für
eine Desktop-Anwendung und Sonstwas-Anwendung betrachtet. Es lässt
sich messen, dass verbindungsloses Arbeiten die Last auf dem Netz/LAN
und beim Server ganz drastisch verringert. Ansonsten kann ich nur auf
das verweisen, was Elmar Boye in seinen Postings geschrieben hat. Du
solltest das vielleicht noch mal gründlich lesen.
Es ist in den meisten Fällen ganz einfach eine (schlechte) Gewohnheit,
wenn man glaubt, serverseitige Cursor und pessimistische Sperren seien
unbedingt notwendig oder gar sinnvoll. Man könnte dann ja gleich
weiterhin mit DAO arbeiten.
Peter Götz
> > ? Nö... Stichwort "Optimistic Concurrency". Es gibt ja nun mehrere
> > Ansätze wie man es umsetzen kann. Mein Favorit: der Timestamp.
Nicht alle DBS stellen TimeStamp zur Verfügung.
> ... der letztendlich auch nichts anderes macht als eine
pessimistische
> Sperre: es wird signalisiert, dass der betreffende Datensatz gerade
in
> Bearbeitung ist.
Nein, das kann ein TimeStamp nicht signalisieren. Er wird geschrieben
und dann hat er eben einen bestimmten Wert. Ob an diesem Datensatz
gerade jemand arbeitet oder nicht kann dieser Wert nicht verraten. Er
kann bestenfalls verraten, dass der Datensatz verändert worden ist,
wenn man den TimeStamp mit einem früher gespeicherten Wert vergleicht.
Da ist die Änderung aber bereits passiert und das ist was deutlich
anderes, als wenn die Änderung gerade im Gange ist.
> Nur dass der ganze Mechanismus zur Auswertung dieses "Signals" jetzt
in
> die Anwendung verlagert wird und jeder Programmierer das Thema etwas
> anders angeht,
... was ihm schon mal die Möglichkeit eröffnet, seine Routinen genau
auf die jeweiligen Anwendungserfordernisse hin zu optimieren.
> wo Spezialisten entsprechende Routinen im Server
> implementiert und optimiert haben. Das ist wohl das beste Beispiel
für
> "das Rad neu erfinden". Wo ist hier der Fortschritt?
Der Fortschritt liegt z.B. darin, dass ein Server, der von mehreren
tausend Benutzern beansprucht wird, ganz drastisch entlastet wird, die
Zeiten in denen Datensätze gesperrt sind enorm verringert werden ( von
Sekunden oder sogar Minuten auf wenige Millisekunden) und alle Clients
von der dadurch steigenden Performance des gesamten Systems
profitieren.
Klaus P. Pieper
Peter Götz schrieb:
> Hallo Klaus,
>
>>... der letztendlich auch nichts anderes macht als eine
>> pessimistische Sperre: es wird signalisiert, dass der
>> betreffende Datensatz gerade in Bearbeitung ist.
>
> Nein, das kann ein TimeStamp nicht signalisieren. Er wird geschrieben
> und dann hat er eben einen bestimmten Wert. Ob an diesem Datensatz
> gerade jemand arbeitet oder nicht kann dieser Wert nicht verraten. Er
> kann bestenfalls verraten, dass der Datensatz verändert worden ist,
> wenn man den TimeStamp mit einem früher gespeicherten Wert vergleicht.
> Da ist die Änderung aber bereits passiert und das ist was deutlich
> anderes, als wenn die Änderung gerade im Gange ist.
im Zusammenhang mit dem Thema "Datensatz sperren" dient der
Timestamp-Wert eines speziellen, genau dafür vorgesehenen, Feldes aber
doch genau dazu: einer anderen Anwendung oder einem anderen Benutzer
derselben Anwendung den "Belegt-Status" (nenn es wie du willst) anzuzeigen.
>
> Der Fortschritt liegt z.B. darin, dass ein Server, der von mehreren
> tausend Benutzern beansprucht wird, ganz drastisch entlastet wird, die
> Zeiten in denen Datensätze gesperrt sind enorm verringert werden ( von
> Sekunden oder sogar Minuten auf wenige Millisekunden) und alle Clients
> von der dadurch steigenden Performance des gesamten Systems
> profitieren.
Wie gesagt: es geht nicht immer um mehrere tausend Benutzer, auch die
Zeit, die ein Datensatz gesperrt ist, ist oft nicht relevant.
Da fällt mir noch ein ganz altes Beispiel für optimistische Sperren ein.
Aus einer Zeit, in der kaum mit relationalen Datenbanken gearbeitet und
"ordentliche" Anwendungen noch in Cobol oder Fortran geschrieben wurden:
in einem Reisebüro wurde in mühevoller Kleinarbeit eine Flugreise mit
Hotel und allem was dazugehört herausgesucht. Flugdaten eingegeben.
Gefreut, noch zwei Plätze verfügbar. Bearbeiter gab die Daten ein, wurde
unterbrochen, beim Abspeichern war der Flug dann weg... Tja, Pech
gehabt. Hat auch nicht geholfen, dass der Programmierer, wenn er nur
gewollt hätte, das ganze hätte besser absichern können. Er hat es eben
nicht getan (war ihm wohl zu viel Arbeit, $Kunde hat es nicht bezahlt
oder es war ihm egal). Es mag an diesem Erlebnis liegen, dass der
begriff "optimistische Sperre" seitdem bei mir nicht mehr unbedingt
positiv besetzt ist ;-)
Klaus P. Pieper
Peter Götz schrieb:
> Hallo Klaus,
>
>
>>>? Nö... Stichwort "Optimistic Concurrency". Es gibt ja nun mehrere
>>>Ansätze wie man es umsetzen kann. Mein Favorit: der Timestamp.
>
> Nicht alle DBS stellen TimeStamp zur Verfügung.
die verbreiteten DBMSe stellen Timestamp schon zur Verfügung, allerdings
sind es manchmal ganz normale Datentypen mit Datum + Zeit. Die habe ich
hier gemeint.
Peter Götz
> > 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.
>
> hier liegt wohl der Grund für die unterschiedlichen Ansätze. In
meinem
> Fall (und möglicherweise auch bei einigen anderen Leuten) habe ich es
> meistens mit größeren Tabellen zu tun (deutlich über 10.000
Datensätze),
Nun klammere Dich mal nicht an 10.000 Datensätze, das können auch
weniger, aber auch deutlich mehr sein. In meiner Praxis sind Tabellen
mit mehreren Millionen Datensätzen keineswegs ungewöhnlich.
> dafür aber nur mit einigen Benutzern. Als Größenordnung zwischen 5
und
> 50. Der Anteil der gesperrten Datensätze ist also viel kleiner als
von
> dir angenommen.
Was die Systemlast insgesamt natürlich relativ gering ausfallen lässt,
aber am Prinzip absolut nichts ändert.
> > Ob Web- oder sonstige Anwendung, spielt erst mal keine Rolle,
solange
> > mehrere Benutzer auf eine gemeinsame Datenbank zugreifen. Man kann
> > obiges Beispiel ja auch noch drastischer darstellen, wenn man eine
> > Tabelle mit 1000 Datensätzen und 500 ständig ändernden Benutzer
nimmt.
> > Dann wäre ständig annähernd die Hälfte aller Datensätze gesperrt.
> > Flüssiges Arbeiten wäre in diesem Fall wohl kaum noch möglich.
>
> Dieses Beispiel ist kein solches. Egal ob optimistisches oder
> pessimistisches Locking - bei 1000 Datensätzen und 500 ständig
> *ändernden* Benutzern ist das Chaos so oder so vorprogrammiert.
Das ist durchaus ein Beispiel aus der Praxis einer industriellen
Fertigung.
Da werden ständig z.B. 1000 verschiedene Artikel gefertigt und einem
Lager zugebucht und gleichzeitig ständig wieder entnommen und
entsprechend ausgebucht. Ein Chaos entsteht dabei keineswegs, das läuft
in absolut geordneten Bahnen ab.
> Bei 1000
> datensätzen sind sowieso nur wenige Änderungen pro Zeiteinheit
möglich,
Die mögliche Anzahl wird halt im Wesentlichen dadurch bestimmt, wie
lange ein Datensatz gesperrt ist.
Und da macht es halt schon einen gewaltigen Unterschied ob ein
Datensatz z.b. 30 Sekunden oder eben nur 10 oder 20 Millisekunden
tatsächlich gesperrt ist.
> Lesezugriffe auf den Datenstand vor der Bearbeitung muss jedoch
möglich
> sein.
Opt. Locking verhindert das doch nicht.
> > Wenn Müller einen Datensatz gerade ändert und Schulze holt sich
diesen
> > Datensatz ebenfalls, um etwas daran zu ändern, dann
... schnipp ...
> > Eine ganz simpler Mehrbenutzerkonflikt und eine ebenso simple
> > Konfliktlösung.
>
> Stimmt, ein ganz normaler Konflikt mit einer aufwändigen Lösung.
Was um Himmels Willen ist denn daran aufwendig?
Schau Dir mal den Code an, den das DBS abarbeiten muss, um Deine
bevorzugten pess. Sperren zu realisieren.
Nur weil Du diesen Code nicht siehst und vermutlich auch nicht kennst,
heisst das nicht, dass er nicht abgearbeitet werden müsste und
Rechenzeit konsumiert.
> Ein
> Konflikt, den man zahlender Kundschaft genau einmal zumuten darf.
Wenn
> dieses Verhalten nicht schnellstens abgestellt wird, sieht sich der
> Kunde nach einam anderen Produkt um.
Welches Verhalten soll abgestellt werden?
> Seine Zeit ist nämlich teuer.
Und genau deshalb sollte man alles tun, um die Performance des gesamten
Systems nicht mit völlig unnötig langen Sperren in die Knie zu zwingen.
> Und
> entweder Müller oder Schulze hat gerade seine wertvolle Arbeitszeit
mit
> Sozialabgaben und allem was dazu gehört "zum Fenster hinausgeworfen".
Das solltest Du Dir nochmal genauer ansehen.
Gerade wenn Du sagst, dass bei Deinen Anwendungen nur eine kleine
Anzahl von Benutzern auf die DB zugreift, heisst das, dass
Konfliktsituationen äusserst selten auftreten werden. Wobei wird dann
wohl mehr Zeit verschwendet?
Wenn die Systemleistung durch unnötiges Sperren von Datensätzen
eingebremst wird und dann auch noch immer wieder mal auf das Freiwerden
eines Datensatzes gewartet werden muss
oder
wenn ein Benutzer vielleicht 1 oder 2 mal in der Woche einige wenige
Sekunden warten und dann nochmal auf seinen Speicherbutton klicken
muss.
> Selbst bei simplen dateibasierten Produkten wie bei einer
> Textverarbeitung wird Schulze darauf hingewiesen, dass die Datei
gerade
> von Müller bearbeitet wird.
Wenn die Textverarbeitung "notepad" heisst, ist das allerdings nicht
so.
> Vielleicht liegt auch hier ein Missverständnis vor. "Pessimistische
> Sperre" heißt ja nicht unbedingt, dass Schulze nichts machen kann,
> solange Müller den Datensatz geöffnet hält und in der Mittagspause
ist.
Natürlich kann er auch was machen.
Er kann den Datensatz anschauen, ein Liedchen trällern oder auch
Mittagspause machen, nur das was er wirklich will, nämlich den
Datensatz ändern, das kann er nicht.
> Es sollte so sein, dass Schulze darauf hingewiesen wird, dass Müller
den
> Datensatz bearbeitet.
Schulze wird dann vielleicht sagen: "schon wieder dieser Bremser
Müller" aber ansonsten bringt ihn das nicht weiter. Er will ja seinen
Datensatz ändern. Anrufen kann er Müller auch nicht, weil der gerade
Mittagspause macht oder vielleicht auf dem Örtchen sitzt.
> Dann kann Schulze entweder einen anderen Vorgang
> bearbeiten
Nun könnte Schulze aber z.B. Mitarbeiter eines Reisebüros sein. Vor ihm
sitzt ein Kunde und der möchte nun seine Reise buchen, kann er aber
nicht, weil Müller wie schon erwähnt Mittagspause macht oder auf dem
Örtchen sitzt. Schulze sagt also dem Kunden, kommen sie in einer Stunde
wieder, wenn wir Glück haben ist Müller dann wieder da und lässt uns
weiterarbeiten oder kommen Sie besser gleich erst morgen früh um 8 Uhr,
Müller kommt meist zu spät zur Arbeit und wenn er dann endlich da ist,
liest er erst mal die Zeitung. Gute Chancen also, dass wir dann Ihre
Buchung machen können.
> oder man kann sich darüber klar werden, warum ein Datensatz
> zur gleichen Zeit bei beiden zur Bearbeitung anliegt. Das ist aber
ein
> organisatorisches Problem, keins der EDV.
>
> >
> > Was ist besser,
> >
> > a.) 10% aller Datensätze einer Tabelle als gesperrt zu
kennzeichen
> >
> > oder
> >
> > b.) < 0,01 % weniger aller Datensätze der selben Tabelle zu
> > sperren?
>
> Da gibt es kein "besser" oder "schlechter". Das hängt immer vom
> konkreten Anwedungsfall ab.
Du wirst aber hoffentlich nicht abstreiten wollen, dass die
Wahrscheinlichkeit auf einen gesperrten Datensatz zu treffen bei 10%
gesperrter Datensätze deutlich höher ist als bei nur 0,01%.
Peter Götz
> deine Anwender möchte ich haben ... Was meinst du, was passiert, wenn
> bei x ¤ Stundensatz die Eingabe automatisch verworfen wird, nur weil
ein
> Telefongespräch dazwischen kam? Und wenn das immer wieder passiert?
Ich denke, es hat wenig Sinn, eine Diskussion fortzuführen, die Du
offenbar überhaupt nicht verstehst.
Lies halt einfach mal meine Postings und versuche, das was ich da an
Sperrmechanismen beschreibe auch zu verstehen.
Bis dahin lassen wir es erst mal gut sein.
Klaus P. Pieper
Peter Götz schrieb:
> Hallo Klaus,
>
>>Das eigentliche Problem ist, dass der Programmieraufwand bei
>>optimistischen Sperren deutlich höher ist.
>
>
> Was ist besser,
> ein klein wenig mehr Programmcode oder ein beachtlich höherer
> Ressourcenverbrauch auf dem LAN und beim Server und eine messbar
> geringere Performance des gesamten Systems?
den Kunden / Anwender und damit mich interessieren in erster Linie die
Gesamtkosten. Bei hohen Anwenderzahlen spielen die Programmierkosten
naturgemäß eine geringere Rolle, dafür wird man stärkeren Wert auf den
Ressourcenverbrauch, Mindestleistung des Servers etc. legen. Bei mir ist
das anders, wenige (aber immer mehr als ein) Anwender, der
Ressourcenverbrauch spielt dabei keine große Rolle. Die
Programmierkosten schon.
>>Wir haben gerade unsere erste
>>Musteranwendung komplett auf optimistische Sperren umgestellt. Der
>>Aufwand gegenüber klassischem Record-Locking ist (geschätzt) doppelt
> > so hoch und bringt dem Benutzer keinerlei Vorteile.
>
> Also das "doppelt so hoch" würde ich aber schon mal genauer
> hinterfragen.
Und wenn es nur 20% wären, wären es genau 20% zu viel. Eigentlich
erwartet man von einem neuen Ansatz sogar mehr Produktivität, nicht
weniger. Was würdest du denn sagen, wenn das neue Automodell bei
ansonsten gleichen Rahmenbedingungen (gleiche Leistung, Steuererhöhungen
usw. nicht berücksichtigt etc.) auf einmal 20% mehr Kosten verursachen
würde als der Vorgänger?
>
>>Wenn ein Benutzer einen Beleg bearbeitet und ein anderer Benutzer will
>>den gleichen Beleg bearbeiten, *muss* der zweite Benutzer *bei Beginn
>>seines Vorgangs* darüber informiert werden, dass der Beleg gerade
>>gesperrt ist.
>
>
> Und genau diese Forderung sollte man mal genau überprüfen.
> Muss der Benutzer wirklich schon zu Beginn seiner Bearbeitung wissen,
> dass ein anderer Benutzer auch an diesem Datensatz arbeitet?
Ja, ja und nochmals ja. Wenn er erst einmal seine Daten eingegeben hat,
ist es zu spät. Zeit und Aufwand ist teuer. Und verärgerter Kunde sucht
sich eine andere Lösung.
> Das trifft bestenfalls dann zu, wenn die vorzunehmende Änderung die
> Kenntnis des bisherigen (momentanen) Datenzustandes unumgänglich
> notwendig macht.
> Überlege mal gründlich, wann das wirklich der Fall ist.
> Trifft dies in sehr seltenen Fällen wirklich zu, lohnt es sich auch da
> noch, zu überlegen, ob diese Situation durch ein geschickteres
> Programmdesign nicht vermieden werden kann.
Sicher kann man das in vielen Fällen. Aber ich bezweifele, das der
Aufwand hierfür in einem günstigen Verhältnis zu dem Nutzen ist. Die
Frage stellt sich doch: es gibt ein geeignetes Programmiermodell
(pessimistic locking). Das ermöglicht eine bestimmte Problemlösung zu
gewissen Kosten. Diese Kosten setzen sich aus Programmierkosten und
anderen Kosten (z.B. für Hardware) zusammen.
Nun kommt ein neues Programmiermodell, bei dem die Programmierkosten
höher sind als vorher, die anderen Kosten (wie für die Hardware) unter
bestimmten Voraussetzungen (z.B. 1000 Nutzer und mehr) aber niedriger.
Das ist schön und gut, nur habe ich keine 1000 Nutzer und mehr, muss
dafür aber den häheren Programmieraufwand tragen. In Summe wird es (für
mich, aber ich bin da sicher kein Einzelfall) teurer. Das ist die
eigentliche Kritik.
>
> In ca. 99% der Fälle wird es ohnehin so sein, dass der Datensatz
> tatsächlich gerade von keinem anderen Benutzer bearbeitet wird
> (vorausgesetzt es werden nicht viele Datensätze unnötig lange durch
> pessimistische Sperren blockiert) und somit ohnehin kein akutes
> Mehrbenutzerproblem besteht.
OK.
> Das verbleibende 1% lässt sich mit sehr wohl überschaubarem
> Programmieraufwand und ohne sonderliche Schwierigkeiten abarbeiten.
Genau da unterscheiden sich unsere Ansichten. Vermutlich auch unsere
Erfahrungen und / oder unsere Aufgabenstellungen.
>
>>Der gesamte Ansatz mit dem "optimistic locking" ist für mich
> (zumindest
>>bei Forms-Anwendungen) der größte Rückschrift im .NET Framework
>>gegenüber den früheren Methoden.
>
> Das klingt ein wenig nach:
> "Das haben wir schon immer so gemacht, warum sollen wir es jetzt anders
> machen?"
> Ich sehe beim verbindungslosen Betrieb wie ihn ADO ermöglicht und
> ADO.net erzwingt eigentlich nur Vorteile. Auf diese Vorteile möchte ich
> nicht verzichten, nur weil ich vielleicht alle 100 Jahre mal die
> Notwendigkeit habe, einen Datensatz etwas länger zu sperren und dafür
> ein paar Zeilen Code schreiben muss.
Es ist nicht wichtig wie es klingt. Ich vermute, dass du auch anderer
Ansicht wärst, wenn es bei dir nicht alle 100 Jahre, sondern häufig und
in wechselnden Aufgabenstellungen vorkäme. Ich habe auch überhaupt
nichts dagegen, wenn neue & zusätzliche Methoden (hier das
verbindungslose ADO.NET) angeboten werden. Es ist sicher in vielen
Fällen gut einsetzbar. Freu dich, wenn du zu den Glücklichen gehörst,
deren Aufgabenstellung genau dazu passt. Aber bitte glaube nicht, dass
es keine anderen Problemstellungen gibt.
>
> Es spielt überhaupt keine Rolle ob man es für eine Web-Anwendung, für
> eine Desktop-Anwendung und Sonstwas-Anwendung betrachtet. Es lässt
> sich messen, dass verbindungsloses Arbeiten die Last auf dem Netz/LAN
> und beim Server ganz drastisch verringert.
Wie gesagt, die Last auf dem Netz und auf dem Server spielen bei mir
keine große Rolle. Daher sind die von Elmar Boye angeführten Links zwar
richtig und für grundsätzliche Betrachtungen wichtig, aber für mich in
Anbetracht der konkreten Aufgabenstellung nur wenig relevant.
Klaus P. Pieper
Peter Götz schrieb:
>
> Ich denke, es hat wenig Sinn, eine Diskussion fortzuführen, die Du
> offenbar überhaupt nicht verstehst.
dass wir beide keine gemeinsame Sprache sprechen, ist nun wirklich kein
Geheimnis. Diese Diskussion hatten wir schon einmal. Ich habe nichts
gegen unterschiedliche Meinungen, die (auch) auf unterschiedlichen
Erfahrungen beruhen. Aber du *willst* ja anscheinend nicht sehen, dass
es etwas außerhalb deines Erfahrungsbereichs gibt. Lass' mal gut sein.
Klaus P. Pieper
Peter Götz schrieb:
>
>>>Eine ganz simpler Mehrbenutzerkonflikt und eine ebenso simple
>>>Konfliktlösung.
>>
>>Stimmt, ein ganz normaler Konflikt mit einer aufwändigen Lösung.
>
>
> Was um Himmels Willen ist denn daran aufwendig?
> Schau Dir mal den Code an, den das DBS abarbeiten muss, um Deine
> bevorzugten pess. Sperren zu realisieren.
> Nur weil Du diesen Code nicht siehst und vermutlich auch nicht kennst,
> heisst das nicht, dass er nicht abgearbeitet werden müsste und
> Rechenzeit konsumiert.
absolut richtig. Nur dass dieser Code einmal von entsprechenden
Datenbank-Spezialisten programmiert und optimiert wird anstatt von
x-tausend Anwendungs-Programmierern, die im Durchschnitt sicher kein
besseres Ergebnis erzielen.
>
>>Und
>>entweder Müller oder Schulze hat gerade seine wertvolle Arbeitszeit
>>mit Sozialabgaben und allem was dazu gehört "zum Fenster hinausgeworfen".
>
> Das solltest Du Dir nochmal genauer ansehen.
> Gerade wenn Du sagst, dass bei Deinen Anwendungen nur eine kleine
> Anzahl von Benutzern auf die DB zugreift, heisst das, dass
> Konfliktsituationen äusserst selten auftreten werden.
Nicht unbedingt. Irgendwo in diesem Thread wurde schon einmal das
Beispiel der Buchhaltung gebracht, in dem eine Kunde zwei Sachbearbeiter
kurz nacheinander anrief. Durchaus praxisgerecht, auch bei kleiner
Anwender-Anzahl.
>> Selbst bei simplen dateibasierten Produkten wie bei einer
>> Textverarbeitung wird Schulze darauf hingewiesen, dass die Datei
>> gerade von Müller bearbeitet wird.
>
> Wenn die Textverarbeitung "Notepad" heisst, ist das allerdings nicht
> so.
Gehen dir langsam die Argumente aus, oder was soll die Polemik?
>
> Natürlich kann er auch was machen.
> Er kann den Datensatz anschauen, ein Liedchen trällern oder auch
> Mittagspause machen, nur das was er wirklich will, nämlich den
> Datensatz ändern, das kann er nicht.
Wie gesagt, deine Anwender möchte ich haben. Meine haben eigentlich
immer etwas zu tun. Auch wenn dieser Datensatz gerade von Müller
bearbeitet wird, dreht "mein" Schulze nicht Däumchen. Aber vielleicht
ist das bei deinen Anwendern ja anders.
>>>
>>> a.) 10% aller Datensätze einer Tabelle als gesperrt zu
>>> kennzeichen oder
>>>
>>> b.) < 0,01 % weniger aller Datensätze der selben Tabelle zu
>>>sperren?
>>
>>Da gibt es kein "besser" oder "schlechter". Das hängt immer vom
>>konkreten Anwedungsfall ab.
>
> Du wirst aber hoffentlich nicht abstreiten wollen, dass die
> Wahrscheinlichkeit auf einen gesperrten Datensatz zu treffen bei 10%
> gesperrter Datensätze deutlich höher ist als bei nur 0,01%.
Nein, bestimmt nicht. Bei den Fällen, die mich interessieren, sind es
eigentlich immer unter 0,05% (sagen wir einmal 100.000 Datensätze, bis
zu 50 Benutzer). Da ist die reine "statistische" Wahrscheinlichkeit
schon recht gering, das ist wahr. Die "organisatorische"
Wahrscheinlichkeit (siehe oben, der Kunde, der zweimal anruft), ist
davon aber vollkommen unabhängig.
Vieles an diesem Thema erinnert mich an die "Grabenkämpfe" aus dem
Bereich der Netzwerke Ende der 80er Jahre des vorigen Jahrhunderts.
CSMA/CD (hier die optimistischen Sperren) gegen Token Passing (hier
pessimistische Sperren).
Bekanntlich hat sich mit Ethernet CSMA/CD zunächst in vielen Bereichen
durchgesetzt. Und das Zugriffsverfahren interessiert heute weder die
Programmierer noch die Anwender.
Dies hauptsächlich aus zwei Gründen: erstens wurden die Komponenten sehr
preiswert. Zweitens gab es mit TCP/IP eine Schicht, die dem
Programmierer und den Anwendern die Sorge um das bessere
Zugriffsverfahren vollkommen abnahm. Wenn es eine solche abstrakte
Zugriffsschicht auch für ADO.NET geben würde, wäre es mir vollkommen
egal, welcher Sperrmechanismus zu Grunde liegen würde.
Peter Fleischer
...
> im Zusammenhang mit dem Thema "Datensatz sperren" dient der
> Timestamp-Wert eines speziellen, genau dafür vorgesehenen, Feldes aber
> doch genau dazu: einer anderen Anwendung oder einem anderen Benutzer
> derselben Anwendung den "Belegt-Status" (nenn es wie du willst)
> anzuzeigen.
Klaus,
das ist falsch. Mit einem TimeStamp kannst du das nicht organisieren. Du
braucht ein Feld mit einem Verfallsdatum/-zeit. Das ist etwas anderes.
Peter
Klaus P. Pieper
Peter Fleischer schrieb:
ach ja, beim SQL-Server hat Timestamp eine besondere Bedeutung. Bei
anderen DBMSen (die ich hauptsächlich benutze) bedeutet "Timestamp"
einfach eine Kombination aus Datum und Zeit einer Auflösung > 1 Sekunde.
Ich benutze den SQL Server selten, vermutlich nennt man den Typ hier
datetime.
Peer Schlephack
welche Lösung hälst du denn jetzt für gut Peter?
"Peter Götz" <gssg_...@t-online.de> schrieb im Newsbeitrag
news:uLU2sW1z...@TK2MSFTNGP03.phx.gbl...
> Hallo Paul,
>
>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>> vermeiden sollte, und insbesondere interessiert mich, warum die
>> Alternative besser ist.
>
> Je mehr Benutzer über die gesamte Zeit ihrer Dateneingabe den
> jeweiligen Datensatz sperrren, um so grösser wird die
> Wahrscheinlichkeit, dass andere Benutzer, die den selben Datensatz
> bearbeiten wollen, warten müssen, bis er endlich mal wieder freigegeben
> wird. In dieser Zeit müssen sie immer wieder mal versuchen, auf diesen
> Datensatz zuzugreifen um zu sehen, ob er immer noch gesperrt oder
> vielleicht jetzt doch schon frei ist.
>
> Wenn die Anwendung ein solches pessimistisches Sperren nicht unbedingt
> erfordert, dann ist dieses pessimistisches Sperrverfahren absolut
> kontraproduktiv.
>
> Man muss schon sehr lange und sehr gründlich nachdenken, bis einem ein
> konkreter Anwendungsfall einfällt, der solch pessimistische Sperren
> wirklich unumgänglich notwendig macht. Ich habe Dich ja schon mal
> gefragt, ob Dir auf Anhieb ein solcher Anwendungsfall einfällt. Die
> Antwort darauf bist Du bisher schuldig geblieben.
Peter Götz
> im Zusammenhang mit dem Thema "Datensatz sperren" dient der
> Timestamp-Wert eines speziellen, genau dafür vorgesehenen, Feldes
aber
> doch genau dazu: einer anderen Anwendung oder einem anderen Benutzer
> derselben Anwendung den "Belegt-Status" (nenn es wie du willst)
anzuzeigen.
Das ist schlichter Unsinn.
Wie soll ein TimeStamp zu erkennen geben, ob ein Datensatz gerade in
Bearbeitung ist oder nicht.
Eine Diskussion, bei der einer die simpelsten Dinge offenbar nicht
begreift, ist sinnlos.
Deshalb lassen wir das nun besser.
Peter Fleischer
...
>>> im Zusammenhang mit dem Thema "Datensatz sperren" dient der
>>> Timestamp-Wert eines speziellen, genau dafür vorgesehenen, Feldes
>>> aber doch genau dazu: einer anderen Anwendung oder einem anderen
>>> Benutzer derselben Anwendung den "Belegt-Status" (nenn es wie du
>>> willst) anzuzeigen.
>>
>> Klaus,
>> das ist falsch. Mit einem TimeStamp kannst du das nicht
>> organisieren. Du braucht ein Feld mit einem Verfallsdatum/-zeit. Das
>> ist etwas anderes.
>
> ach ja, beim SQL-Server hat Timestamp eine besondere Bedeutung. Bei
> anderen DBMSen (die ich hauptsächlich benutze) bedeutet "Timestamp"
> einfach eine Kombination aus Datum und Zeit einer Auflösung > 1
> Sekunde. Ich benutze den SQL Server selten, vermutlich nennt man den
> Typ hier datetime.
Klaus,
solche Datenbanksysteme, die als TimeStamp eine Kombination aus Datum und
Zeit einer Auflösung > 1 Sekunde nutzen, kannst du gleich auf den Schrott
werfen. Wie soll man bei denen die Reihenfolge bei Einträgen erkennen, die
den gleichen TimeStamp haben, d.h. zur gleichen Sekunde geschrieben wurden?
Beim SQL-Server wird das zweifelsfrei so gemacht, dass man zwei TimeStamps
mit > oder < vergleichen kann und bekommt genau die richtige Reihenfolge.
Peter
Peter Fleischer
> Hallo zusammen,
>
> welche Lösung hälst du denn jetzt für gut Peter?
Peer,
ich bin zwar nicht der Peter, aber es gibt keine "gute Lösung allgemein".
Ein pessimistisches Sperren braucht man z.B. in Reservierungssystemen. Ein
optimistisches Sperren sollte so oft wie möglich anstelle eines
pessimistischen Sperrens angewandt werden. Man kann durch eine Vielzahl von
"Tricks" auch die Kollisionsrate reduzieren. Dazu zählt z.B. das Update nur
der Felder, die wirklich geändert wurden. Bei organisatorischer Trennung der
Aufgabengebiete der Mitarbeiter gibt es in diesem Falle trotz fehlender
pessimistischer Sperre bei der Bearbeitung des gleichen Datensatzes keine
Konflikte.
Peter
Peter Götz
> welche Lösung hälst du denn jetzt für gut Peter?
Es gibt nicht die gute Lösung.
Du musst erst mal überlegen, welche Anforderungen Dein konkreter
Anwendungsfall stellt.
Dabei kannst Du erst mal grob 3 verschiedene Gruppen betrachten.
1.) Zugriffe nach dem Prinzip "wer zuletzt speichert, hat gewonnen".
Dies stellt die geringsten Anforderungen in Sachen
Mehrbenutzerkonflikte.
Beispiel wäre eine Bestandverwaltung in einem Lager.
Benutzer A gibt einen Lagerzugang ein, addiert damit
zum bisherigen Bestand die neue Menge hinzu und
speichert.
Benutzer B gibt eine Lagerentnahme ein und subtrahiert
damit vom bisherigen Bestand die entnommene Menge.
In welcher Reihenfolge die Zugänge und Entnahmen
gespeichert werden ist völlig egal.
Eine Satzsperre ist nicht notwendig. Auch zwischenzeitliche
Änderungen am Datensatz (Bestand) haben keine
nachteiligen Folgen.
2.) Zugriffe bei denen der Benutzer informiert werden muss,
falls seit Beginn seiner Änderungseingabe sein Datensatz
durch einen anderen Benutzer verändert worden ist.
Dies lässt sich mit einem UpdateCommand erkennen, dessen
Where-Klausel alle Felder auf OriginalValues prüft. Wurde
der Datensatz von einem anderen Benutzer verändert,
löst dieser UpdateCommand einen Fehler aus, auf den
man (der Programmcode) reagieren kann.
3.) Zugriffe bei denen vom Beginn der Änderungseingabe bis
zum Ende der Ausführung des UpdateCommands der
akt. Datensatz durch andere Benutzer nicht verändert
werden darf.
Dieser Fall lässt sich mit dem von mir nun schon mehrfach
beschriebenen Zeitfeld (Now + gewünschte Sperrzeit)
realisieren. Dabei ist die Regel einzuhalten: Ein Datensatz
dessen Zeitfeld leer ist oder einen Zeiteintrag enthält,
der in der Vergangenheit liegt, gilt als frei.
Ein Datensatz dessen Zeiteintrag in der Zukunft liegt,
gilt als gesperrt, weil er gerade von einem anderen Benutzer
bearbeitet wird.
Peer Schlephack
onRowupdate oder wie der sich nennt?
"Peter Götz" <gssg_...@t-online.de> schrieb im Newsbeitrag
news:Okqr8OE0...@TK2MSFTNGP06.phx.gbl...
Daniel Kuppitz
> > In einem grossen Unternehmen sollen also beispielsweise einige tausend
> > Mitarbeiter einen grossen Teil ihrer Arbeitszeit damit verbringen auf
> > das Freiwerden eines zu bearbeitenden Datensatzes zu warten?
>
> 1) es gibt nicht nur große Unternehmen mit einigen tausend Mitarbeitern
> 2) auch in großen Unternehmen können die Leute schon einmal etwas
> anderes tun, solange ein Datensatz in Bearbeitung ist.
>
> Stell dir doch einfach einmal ein großes Unternehmen mit Maschinen vor.
> Solange eine Maschine mit dem Artikel A belegt ist, kann sie eben für
> Artikel B nicht eingerichtet werden. Die Mitarbeiter wissen das und
> organisieren sich entsprechend. Vereinfacht dargestellt suchen sie sich
> eine freie Maschine, für die auch Aufträge vorliegen.
Jetzt vergleichst Du Äpfel mit Birnen, das kannst Du so nicht sehen.
Gerade das ist doch der Vorteil an der Softwarelösung - wir können
effizienter arbeiten, weil eben mehrere Zugriffe gleichzeitig
stattfinden können. Wäre das nicht so, könnten wir uns auch alle an
eine Schreibmaschine setzen und ein Blatt Papier von einem zum
nächsten Mitarbeiter reichen.
Wenn ein Team an einem (Software-)Projekt arbeitetet, muss auch keiner
mit der Entwicklung seiner Komponente auf den nächsten warten, weil
der gerade seine Komponente in der gleichen Solution bearbeitet.
Also generell sind die Vergleiche hier im Thread sehr weit hergeholt
und es ist erstaunlich wie dieser Thread wächst, wenn man mal einen
Tag nicht reinschaut ;-).
--
MfG,
Daniel Kuppitz
Klaus P. Pieper
Daniel Kuppitz schrieb:
>>Stell dir doch einfach einmal ein großes Unternehmen mit Maschinen vor.
>>Solange eine Maschine mit dem Artikel A belegt ist, kann sie eben für
>>Artikel B nicht eingerichtet werden. Die Mitarbeiter wissen das und
>>organisieren sich entsprechend. Vereinfacht dargestellt suchen sie sich
>>eine freie Maschine, für die auch Aufträge vorliegen.
> Jetzt vergleichst Du Äpfel mit Birnen, das kannst Du so nicht sehen.
"Vergleiche hinken von Berufs wegen" - das hat schon eimal jemand
gesagt, der mehr davon verstand als ich. Es ging bei dem Beitrag ja nur
darum, dass jemand behauptete, man müsse Däumchen drehen, wenn ein
anderer Benutzer einen Datensatz sperrt. Und diese Annahme ist in vielen
Fällen zumindest sehr fraglich.
Klaus P. Pieper
Peter Fleischer schrieb:
> Klaus P. Pieper wrote:
>>
>>ach ja, beim SQL-Server hat Timestamp eine besondere Bedeutung. Bei
>>anderen DBMSen (die ich hauptsächlich benutze) bedeutet "Timestamp"
>>einfach eine Kombination aus Datum und Zeit einer Auflösung > 1
>>Sekunde. Ich benutze den SQL Server selten, vermutlich nennt man den
>>Typ hier datetime.
>
> Klaus,
> solche Datenbanksysteme, die als TimeStamp eine Kombination aus Datum und
> Zeit einer Auflösung > 1 Sekunde nutzen, kannst du gleich auf den Schrott
> werfen.
sag selbst, bei welchem DBMS ist denn die kleinste Zeiteinheit größer
als eine Sekunde? Aus dem Zusammenhang geht doch eindeutig hervor was
mit "Auflösung > 1 Sekunde" gemeint ist: eine Auflösung, die *besser*
ist als eine Sekunde, also mit Bruchteilen von Sekunden arbeitet.
Üblicherweise 1ms oder 1µs.
Außerdem ist die Reihenfolge der Datensätze in diesem Zusammenhang
belanglos, hier geht es nur um die Dauer einer Sperre. Und *dafür* würde
in den vielen Fällen sogar eine gröbere Auflösung als eine Sekunde
ausreichen.
Klaus P. Pieper
Peter Götz schrieb:
> Hallo Klaus,
>
>>im Zusammenhang mit dem Thema "Datensatz sperren" dient der
>>Timestamp-Wert eines speziellen, genau dafür vorgesehenen, Feldes
> aber
>>doch genau dazu: einer anderen Anwendung oder einem anderen Benutzer
>>derselben Anwendung den "Belegt-Status" (nenn es wie du willst)
> anzuzeigen.
>
> Das ist schlichter Unsinn.
> Wie soll ein TimeStamp zu erkennen geben, ob ein Datensatz gerade in
> Bearbeitung ist oder nicht.
> Eine Diskussion, bei der einer die simpelsten Dinge offenbar nicht
> begreift, ist sinnlos.
und wem die Argumente ausgehen und wer nicht bereit ist, sich Gedanken
zu machen, was der andere überhaupt *gemeint* hat, der fängt an,
persönlich zu werden. Ist das so üblich in St. Georgen?
Lies http://troels.arvin.dk/db/rdbms/#data_types-date_and_time-timestamp
und du siehst, dass MS den Begriff TimeStamp mal wieder (völlig unnötig)
anders benutzt als bei den anderen verbreiteten DBMSen und als im
Standard vorgesehen.
Peter Fleischer
...
>>> anderen DBMSen (die ich hauptsächlich benutze) bedeutet "Timestamp"
>>> einfach eine Kombination aus Datum und Zeit einer Auflösung > 1
>>> Sekunde. Ich benutze den SQL Server selten, vermutlich nennt man den
>>> Typ hier datetime.
>>
>> Klaus,
>> solche Datenbanksysteme, die als TimeStamp eine Kombination aus
>> Datum und Zeit einer Auflösung > 1 Sekunde nutzen, kannst du gleich
>> auf den Schrott werfen.
>
> sag selbst, bei welchem DBMS ist denn die kleinste Zeiteinheit größer
> als eine Sekunde? Aus dem Zusammenhang geht doch eindeutig hervor was
> mit "Auflösung > 1 Sekunde" gemeint ist: eine Auflösung, die *besser*
> ist als eine Sekunde, also mit Bruchteilen von Sekunden arbeitet.
> Üblicherweise 1ms oder 1µs.
Klaus,
da muss ich wohl nochmal die Schule besuchen, um besser Deutsch zu verstehen
und zu erkennen dass Größer in Wiklichkeit Kleiner ist :-)
Peter
Peter Fleischer
...
> http://troels.arvin.dk/db/rdbms/#data_types-date_and_time-timestamp
> und du siehst, dass MS den Begriff TimeStamp mal wieder (völlig
> unnötig) anders benutzt als bei den anderen verbreiteten DBMSen und
> als im Standard vorgesehen.
Klaus,
da hast Recht, dass der Begriff "TimeStamp" gerade bei MS SQL anders genutzt
wird und vielfach zu Missverständnissen führt. Es gibt aber leider keinen
einheitlichen Typ, der eine unikate (für den gesamten Server) Reihenfolge
von Aktivitäten kennzeichnet. Gerade bei Synchronisationsvorgängen ist solch
ein Feld zwingend erforderlich. Ich weiß z.B. nicht, wie man das in DB/2
realisiert. Ich habe mir dort mit einem zusätzliche AutoIncrement geholfen.
Das geht aber immer nur für eine Tabelle separat. Mir hat es aber gereicht.
Peter
Klaus P. Pieper
Peter Fleischer schrieb:
> wird und vielfach zu Missverständnissen führt. Es gibt aber leider keinen
> einheitlichen Typ, der eine unikate (für den gesamten Server) Reihenfolge
> von Aktivitäten kennzeichnet. Gerade bei Synchronisationsvorgängen ist solch
> ein Feld zwingend erforderlich. Ich weiß z.B. nicht, wie man das in DB/2
> realisiert. Ich habe mir dort mit einem zusätzliche AutoIncrement geholfen.
> Das geht aber immer nur für eine Tabelle separat. Mir hat es aber gereicht.
ja, AutoIncrement reicht in vielen Fällen aus. Wie man es bei DB/2
macht, weiss ich auch nicht. Bei Oracle und PostgreSQL benutzt man eine
Sequenz.
Bei Sybase SQL Anywhere gibt es eine Besonderheit beim
Timestamp-Datentyp: wenn dieser mit DEFAULT TIMESTAMP deklariert ist,
enthält er jeweils das aktuelle Änderungsdatum (mit
Sekundenbruchteilen), wird aber bei nahezu gleichzeitigen Änderungen
ggf. um einen festgelegten Wert hochgezählt, um eine DB-weite
Eindeutigkeit herzustellen.
Paul Werkowitz
> Hallo Klaus,
>
>> Das eigentliche Problem ist, dass der Programmieraufwand bei
>> optimistischen Sperren deutlich höher ist.
>
> Was ist besser,
> ein klein wenig mehr Programmcode oder ein beachtlich höherer
> Ressourcenverbrauch auf dem LAN und beim Server und eine messbar
> geringere Performance des gesamten Systems?
>
Auf das Argument mit dem Aufwand, der durch optimistisches Locking zu
treiben ist, hat Klaus in einem nachfolgenden Post ja bereits
geantwortet. Ich möchte dem Folgendes hinzufügen:
- Bedenke auch die Wirkung beim Kunden. Wenn dort nach einer Kollision
eine Fehlerbehandlung gemacht werden muss, brauchst du ein
*zusätzliches* Interface, dass die Leute lernen müssen. Die Erfahrung
zeigt einfach, dass die dann sofort bei der Hotline anrufen und sich das
erklären zu lassen.
Die MEtapher "was der Eine hat, kann der Andere nicht gleichzeitig
haben" kennen die Leute und können damit umgehen.
- Zweitens würde mich mal interessieren, warum Pessimistic Locking
notwendig höheren Resourcenverbrauch und messbar geringere Performance
bedeutet.
>
>> Der gesamte Ansatz mit dem "optimistic locking" ist für mich
> (zumindest
>> bei Forms-Anwendungen) der größte Rückschrift im .NET Framework
>> gegenüber den früheren Methoden.
>
> Das klingt ein wenig nach:
> "Das haben wir schon immer so gemacht, warum sollen wir es jetzt anders
> machen?"
> Ich sehe beim verbindungslosen Betrieb wie ihn ADO ermöglicht und
> ADO.net erzwingt eigentlich nur Vorteile. Auf diese Vorteile möchte ich
> nicht verzichten, nur weil ich vielleicht alle 100 Jahre mal die
> Notwendigkeit habe, einen Datensatz etwas länger zu sperren und dafür
> ein paar Zeilen Code schreiben muss.
>
Es gibt einfach einige Dinge, die sich bewährt haben, und die man gerne
weiter verwenden möchte. Document/View - Architektur ist z.B. eine
davon. Automatische UI-Statusführung in der Idle-Loop ist eine andere.
Dies gabs bei MFC schon eingebaut, bei WinForms gibts das nicht mehr.
Schließen wir daraus, dass wir nun alle Knöpfe, Menüitems,
Toolbarbuttons immer aktiv darstellen sollen, selbst wenn die dahinter
liegende Funktion im aktuellen Kontext nicht möglich ist?
Nein, ich denke nicht. Sondern wir programmieren das manuell wieder
rein, und nehmen das vielleicht sogar zum Anlass, es noch besser und
flexibler zu machen. Nicht das es besonders schwierig wäre, es ist
einfach nur lästig. Jede vernünftige Anwendung braucht sowas. Da wird
doch auch niemand sagen: "Das ist Altes Denken, heute machen wir das
alles anders....."
Ähnlich siehts mit anderen Techniken aus, wozu ich das Thema diese
Threads zähle.
[snip]
>
> Es ist in den meisten Fällen ganz einfach eine (schlechte) Gewohnheit,
> wenn man glaubt, serverseitige Cursor und pessimistische Sperren seien
> unbedingt notwendig oder gar sinnvoll. Man könnte dann ja gleich
> weiterhin mit DAO arbeiten.
Notwendig sicher nicht. Die Sinnhaftigkeit sollte man schon mal
hinterfragen. Insbesondere habe ich den Eindruck, dass konzeptionelle
Schönheit oft vor der praktische Nutzbarkeit bzw. vernünftiger
Kosten/Nutzenrelation gesehen wird, insbesondere von jüngeren Leuten.
Ich sehe es auch so, dass es durchaus eine Reihe von Anwendungen gibt,
fpr die pessimistisches Locking die korrekte Lösung ist. Serverseitiger
Cursor ist eine andere Sache, die wir in einem anderen Thread
diskutieren können.
Grüße - Paule
Paul Werkowitz
> Hallo Peter,
>
> Peter Götz schrieb:
>>
>>>> Eine ganz simpler Mehrbenutzerkonflikt und eine ebenso simple
>>>> Konfliktlösung.
>>>
>>> Stimmt, ein ganz normaler Konflikt mit einer aufwändigen Lösung.
>>
>>
>> Was um Himmels Willen ist denn daran aufwendig?
>> Schau Dir mal den Code an, den das DBS abarbeiten muss, um Deine
>> bevorzugten pess. Sperren zu realisieren.
>> Nur weil Du diesen Code nicht siehst und vermutlich auch nicht kennst,
>> heisst das nicht, dass er nicht abgearbeitet werden müsste und
>> Rechenzeit konsumiert.
>
> absolut richtig. Nur dass dieser Code einmal von entsprechenden
> Datenbank-Spezialisten programmiert und optimiert wird anstatt von
> x-tausend Anwendungs-Programmierern, die im Durchschnitt sicher kein
> besseres Ergebnis erzielen.
>
Hier scheint es sich um verschiedene Definitionen von Aufwand zu
handeln. Ich meine hier nicht den Aufwand, der im Server durch
Rechenzeit und Resourcenverbrauch entsteht, sondern Aufwand der
Softwareentwicklung. Das kostet richtig Geld! - Neben anderen
Nachteilen, die optimistic Locking beim enduser so mit sich bringt.
Paule
Peter Götz
> Wenn ich mich für Variante 2 entscheide, hilft mir da evtl.
> auch der Handler onRowupdate oder wie der sich nennt?
Ich weiss nicht so recht, was genau Du damit meinst.
Vermutlich hast Du per Designer irgendwelche Controls an DataTables
eines DataAdapters gebunden, was die Sache meist nicht gerade
übersichtlich macht und Du selbst wohl nicht so recht die tatsächlichen
Abläufe beim Speichern eines Datensatzes durchschaust.
Das zweite von mir beschriebene Verfahren beruht einfach darauf, dass
man den jeweiligen Update-Command mit einer Where-Klausel ausstattet,
welche aller Felder des Datensatzes mit ihren OriginalValues
vergleicht. Ein solcher UpdateCommand löst einen Fehler aus, wenn seit
dem Einlesen dieses Datensatzes von einem anderen Benutzer auch nur ein
einziges Feld verändert worden ist.
Deine Fehlerbehandlung fängt diesen Fehler ab und nun kann entschieden
werden, was zu tun ist. Die Entscheidung kann u.U. der Programmcode
selbst nach vorgegebenen Kriterien treffen oder aber man informiert den
Benutzer, dass der Datensatz zwischenzeitlich verändert worden ist und
überlässt dem Benutzer die Entscheidung, ob er die zwischenzeitlich am
Datensatz vorgenommenen Änderungen mit seiner eigenen, neuen Änderung
überschreiben will oder eben nicht. Als Entscheidungshilfe könnte dem
Benutzer auch der momentane, akt. Zustand des Datensatzes gezeigt
werden. Wobei man das mit Vorsicht geniessen sollte, denn bis zum
Zeitpunkt zu dem der Benutzer dann letztlich seine Entscheidung
Speichern oder nicht Speichern trifft, könnt der Datensatz ja schon
wieder geändert worden sein. Solche Situationen lassen sich in der
Regel aber durch gut durchdachte Arbeitsabläufe vermeiden.
Der Zeitpunkt zu dem dies geschieht, ist ganz einfach der Zeitpunkt zu
dem der UpdateCommand ausgeführt wird. Ich arbeite in der Regel mit
ungebundenen Controls für die Dateneingabe, weil ich so die absolute
Kontrolle über alle Benutzeraktivitäten behalte und nicht z.B. von
unerwarteten Datensatzwechseln mit impliziten Speicherversuchen
überrascht werden kann. Der Benutzer wählt einen Datensatz zur
Bearbeitung aus, klickt auf einen Button "Ändern" oder wählt einen
entsprechenden Menüeintrag und beginnt dann mit der Eingabe seiner
Daten. Wenn alle Eingaben erledigt sind, klickt der Benutzer auf den
Speicherbutton oder wählt im entsprechenden Menü "Speichern". Dies löst
eine Routine aus, welche die eingegebenen Daten auf formale Richtigkeit
und Plausibilität prüft. Wurde bei dieser Prüfung eine Unstimmigkeit
entdeckt, wird der Benutzer darauf hingewiesen, evtl. der Focus gleich
auf das fehlerhafte Eingabefeld gesetzt und der Benutzer aufgefordert,
seine Eingabe zu korrigieren. Hat die Prüfung keine Unstimmigkeiten
ergeben, wird der UpdateCommand (mit der oben erwähnten Where-Klausel)
ausgeführt und nun gibt es zwei Möglichkeiten. Die erste,
wahrscheinlichere ist, dass der UpdateCommand fehlerfrei abläuft, weil
kein anderer Benutzer am Datensatz zwischenzeitlich etwas geändert hat.
Der zweite, weitaus seltenere Fall ist, dass der Datensatz von einem
anderen Benutzer zwischenzeitlich geändert worden ist und deshalb der
UpdateCommand einen Fehler auslöst, den Deine Fehlerbehandlung nun
entsprechend behandeln kann.
Paul Werkowitz
> Hallo Paul,
>
>>>> das kommt immer drauf an. Optimistic Locking wird zwar immer
>>>> grundsätzlich empfohlen
>>> Meist aus gutem Grund.
>> Ich höre.
>> 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.
>
> 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 nimmt
> man
>> dann 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.
>>> Wieviele und welche konkrete Anwendungsfälle fallen Dir auf Anhieb
> ein,
>>> bei denen pessimistic Locking wirklich unumgänglich erforderlich
> wäre?
>> Keine. 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
Paul Werkowitz
> Hallo Paul,
>
> ich
>> vielleicht bisschen warten, aber ich bin sicher, nichts zu verlieren.
>
> In einem grossen Unternehmen sollen also beispielsweise einige tausend
> Mitarbeiter einen grossen Teil ihrer Arbeitszeit damit verbringen auf
> das Freiwerden eines zu bearbeitenden Datensatzes zu warten?
>
Nein, natürlich nicht. Dass ein Datensatz gerade nicht verfügbar ist,
heißt nicht, dass man darauf warten muss, bis er wieder frei wird. Dies
wäre in der Tat nicht gut.
Sondern es heißt lediglich, dass man diesen Datensatz derzeit nicht
bearbeiten kann. Man wird dann eben etwas anderes tun und später darauf
zurück kommen.
Deswegen meine Einschränkung auf Desktop-Anwendungen. In automatisierten
Produktionssystemen mag das anders sein, weil die Prozesse dann wirklich
warten müssten. Dort ist wahrscheinlich optimistic locking +
nachträgliche Kollisionsbehandlung besser, da der Durchsatzgewinn den
Aufwand wettmachen mag.
Grüße - Paule
Paul Werkowitz
> Hallo Paul,
>
>
> Du verwechselst Timestamp-Feld mit einem Feld das leer ist oder einen
> Wert vom Typ Date enthält.
>
>> das Schweizer Messer der
>> Datenbankprogrammierer - kommt direkt nach der GUID-PK.
>>
>> Löst das Problem, zumindest zum größten Teil. Man kann schnell
>> feststellen, ob jemand den Satz zwischenzeitlich geändert hat.
>
> Nein mit einem Date-Feld kann wird nicht festgestellt ob ein Datensatz
> geändert worden ist, sondern dieses Feld signalisiert einfach nur, ob
> der Datensatz gerade von einem Benutzer zur Bearbeitung reserviert
> worden ist und deshalb nicht verändert werden darf.
>
OOPs - hatte ich falsch verstanden. Was du jetzt hier sagst, ist
allerdings *locking*. Der Datensatz ist reserviert, und darf deshalb
nicht verändert werden.... Ich dachte aus deinen anderen Postings
bisher, dass du genau das nicht wolltest.
Meine Rede..... EoD.
Anmerkung: Selbstverständlich kann man über ein Datumsfeld feststellen,
ob ein Satz geändert wurde. Man braucht blos beim Update die aktuelle
Zeit reinzuschreiben. Wir verwenden allerdings einen einfachen counter,
der beim update hochgezählt wird, um Probleme mit Zeitdifferenzen auf
den clients zu vermeiden, aber das Prinzip bleibt ja gleich.
Das Verfahren spart einfach den Komplettvergleich des gesamten Records,
um eine Änderung bei optimistic locking erkennen zu können.
[Rest der allseits bekannten und unwidersprochenen technischen Aspekte
gesnippt]
Grüße - Paule
Paul Werkowitz
>>
>> Bleibt noch die Frage: wie soll das Interval gewählt werden?
>
> Ganz einfach:
> Man stellt fest, wie lange ein durchschnittlich geübter Benutzer
> braucht, die entsprechende Änderungsmaske auszufüllen, gibt noch einen
> Puffer von ca. 10...20% hinzu und schon hat man eine recht
> praxisgerechte Zeitspanne. Für die besonders langsamen Benutzer
> verlängert man kurz vor Ablauf des Zeitintervals den Zeiteintrag
> nochmal um ein weiteres Interval und das evtl. auch noch ein weiteres
> mal. Wenn der Benutzer dann immer noch nicht auf den Speichern-Button
> geklickt hat, ist er wohl eingeschlafen oder nach Hause gegangen. Man
> (das Programm) beendet dann die Eingabe und verwirft die schon
> eingegebenen Daten.
>
Kann man machen. Bei Vollmond geben wir noch bisschen zu, und wenn
Bayern gestern verloren hat, das Doppelte. Funktioniert immer!
Funktioniert schon, kann man so machen, aber IMHO ist die Lösung mit den
Dateien besser (s.u.) Vorausgesetzt natürlich, man hat Zugriff auf ein
zentrales Verzeichnis.
>> BTW, dieser Ansatz kommt unserer derzeit gewählten Lösung recht nahe:
>> wir verwenden Sperrdateien im Dateisystem. Der Dateiname codiert eine
>> Resource. Es gibt ein Flag (habe ich gerade vergessen, welches), das
>> bewirkt, dass die Datei vom Betriebssystem automatisch gelöscht wird,
>> wenn das ltzte Handle geschlossen wird (also insbesondere auch, wenn
> der
>> client gestorben ist).
>
> Wo soll denn eine solche Datei gespeichert sein?
> Wenn die z.B. auf einem Server liegt und irgendeiner der Clients stürzt
> ab, dann wird diese Datei das niemals erfahren.
>
Doch, natürlich. Das ist ja gerade der Trick. Ich will, dass ein client,
der gestorben ist, seine aquirierten Resourcen nicht weiter belegt. Du
löst das über live-Meldungen und Zeitspanne und sagst: wenn sich einer
über x Zeiteinheiten nicht mehr meldet, ist er tot... Bei mir ist es so,
dass das Betriebssystem dafür sorgt, dass die Datei verschwindet, wenn
das letzte Handle darauf weg ist.
>
>> Voraussetzung ist natürlich, dass alle clients Zugriff auf ein
>> gemeinsames Netz-Verzeichnis haben müssen, was evtl. nicht überall
>> möglich ist.
>
> Warum sollte das, sofern es ein Netz (LAN) gibt, nicht möglich sein?
>
Weil nicht alle Applikationen unbedingt in einem Netz laufen müssen.
Dies ist eine Einschrännkung, die man beachten muss. Wir greifen hier
z.B. auch schon mal mit Wartungsprogrammen übers Internet auf
Kundendaten zu.
>> Grüße - Paule.
>
> Irgendwie versetzt Du mich immer mehr in arges Erstaunen.
>
Das geht nicht nur dir so. Kannst ja mal in der C# - NG nach mir suchen...
Grüße - Paule.
Paul Werkowitz
> Hallo Klaus,
>
>> bei x € Stundensatz die Eingabe automatisch verworfen wird, nur weil
> ein
>> Telefongespräch dazwischen kam? Und wenn das immer wieder passiert?
>
> Ich denke, es hat wenig Sinn, eine Diskussion fortzuführen, die Du
> offenbar überhaupt nicht verstehst.
Das ultimative Killerargument in allen NGs, wenn man nicht mehr weiter
weiß. Tausend mal erlebt.... und jetzt auch hier.
Klaus hat eine einfach zu verstehende Frage gestellt.
>
> Lies halt einfach mal meine Postings und versuche, das was ich da an
> Sperrmechanismen beschreibe auch zu verstehen.
> Bis dahin lassen wir es erst mal gut sein.
>
Ich habe sie ebenfalls gelesen, und kann daraus keine Antwort ableiten.
Es beschränkt isch auf die Darstellung, wie man den Originalrecord, die
von A und B gemachten Änderungen *technisch* vorhalten kann. Leider
sagst du uns nicht, wie der Benutzer B damit umgehen soll. "Speichern
oder verwerfen" alleine kanns nicht sein - siehe Argument von Klaus oben.
Sags uns einfach nochmal. Beachte auch mein anderweitig dargestelltes
Szenario mit dem 100 € Kundenkonto und dem Storno.
Grüße - Paule
Paul Werkowitz
> Paul Werkowitz wrote:
> ...
>>>> "So oft wie möglich vermeiden" Warum eigentlich? Warum sollte man es
>>>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>>>> vermeiden sollte, und insbesondere interessiert mich, warum die
>>>> Alternative besser ist.
>
> Paul,
> pessimistic locking benötigt viel mehr Ressourcen und kann bei intensiver
> Mehrnutzer-Tätigkeit zu Blockierungen führen.
>
> Ein typisches Beispiel ist die Neuanlage von Stammdaten bei tiefer
> Arbeitsteilung in einem Betrieb. Bearbeiter A erfasst den ersten Teil des
> Stammdatensatzes, legt ihn an und bearbeitet ihn weiter; Bearbeiter B muss
> den Datensatz ergänzen. Bearbeiter B muss bei pessimistischer Sperre warten,
> bis Bearbeiter A den ihm zugewiesenen Informationsteil bearbeitet hat. Das
> kann mit Recherchen, Rückfragen usw. verbunden sein und beträchtlich Zeit in
> Aspruch nehmen. Bearbeiter B muss beispielsweise das Kreditorenkonto
> eintragen, was er bei pessimistischer Sperre nicht kann. Man könnte
> natürlich den Stammdatensatz so trennen, dass er nicht den Prinzipien der
> Normalisierung entspricht, sondern den Orgabläufen im Unternehmen. Wenn dann
> die Orgabläufe im Unternehmen geändert werden, muss auch die
> Datenbankstruktur geändert werden. Ein Horrorszenario:-(
In diesem Fall können die beiden Datensatzteile als mehr oder weniger
disjunkt betrachtet werden. Es würde sich empfehlen, dann nicht den
gesamten Satz, sondern die Teile einzeln zu sperren. Pessimistic locking
ist nur dann interessant, wenn man die parallele Veränderung von Daten
unterbinden will. In deinem Fall liegt es ein wenig anders.
Grüße - Paule
Paul Werkowitz
> Hallo Paul,
> Dann fangen wir weniger abstrakt an:
> http://msdn2.microsoft.com/de-de/library/ms190612.aspx
> Transaktionen (Datenbankmodul)
>
> und http://msdn2.microsoft.com/de-de/library/ms190615.aspx
> "Sperren im Datenbankmodul "
>
>> Soweit ich das verstanden habe, geht es beim key range locking
>> immer um mehrere Records.
>
> Nein, sie sind die Grundlage für die Isolationstufe Serializable -
> u. a. Transaktionsmonitoren die Standardeinstellung.
> Und jede niedrigere Isolationsstufe wie Read Committed ist
> geht letztendlich einen Kompromiss (sprich Risiko) ein.
>
OK, jetzt sehe ich schon klarer. Wir benutzen eigentlich immer
serializable, und haben noch nie über etwas anderes nachgedacht. Es
ergab sich noch nie die Notwendigkeit.
>>
>>>> "So oft wie möglich vermeiden" Warum eigentlich?
>
> Die ganz kurze Fassung: Ein heutiges Datenbanksystem hat u. U.
> eine Leistung von einigen Millionen TPC, zum Vergleich:
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> (und auch kleinere bezahlbarere Systeme schaffen einige Zigtausend)
> Wohingegen die Geschwindigkeit von Benutzern in den
> kaum über eine oder zwei pro Sekunde hinauskommt ;-)
>
Gerade deswegen können wir es uns leisten, Performance zu verschenken.
Wir benötigen in unseren Szenarien keine große Datenbankleistung. Jede
Freeware, die einige GB verwalten kann, tuts.
> Greifen wir Dein Buchungsbeispiel auf, und vergessen wir sowohl
> die Seltenheit ihres praktischen Vorkommens wie die Implementierungs-
> schwächen (die Software sollte eine Verbuchung eines Vorgangs direkt
> anzeigen):
>
Egal ob selten oder nicht - für mich ist es wichtig. Wir haben z.B. ein
System, das in Krankenhäusern eingesetzt wird. Da ist die DB-Performance
(in TPS) sekundär.
Und Implementierungsschwäche? Im dargestellten Szenario (verinfacht): B
hat was auf dem Bildschirm, A ändert den gleichen Record. Möchtest du
dann, dass sich die Anzeige bei B automatisch ändert? Mal unabhängig
davon, wie man die Benachrichtigung technisch machen sollte, ist die
Frage, ob man sowas will.
Darüber haben wir uns die Köpfe heißgeredet, sogar Feldstudien gemacht.
Im Endeffekt war es so, dass unsere höchste Instanz, nämlich der
Benutzer, es nicht wollte.
Grüße - Paule
Klaus P. Pieper
Paul Werkowitz schrieb:
>
> Egal ob selten oder nicht - für mich ist es wichtig. Wir haben z.B. ein
> System, das in Krankenhäusern eingesetzt wird. Da ist die DB-Performance
> (in TPS) sekundär.
könnte also z.B. ein Patientenstammblatt mit optionaler Notizfunktion
sein (ich weiß nicht, ob es so etwas wirklich [schon] gibt, ist auch
eigentlich egal, Vergleiche hinken wie die hier aufgeführten Beispiele):
Abteilung A hat also z.B. gerade einen Beinbruch festgestellt und gibt
dazu zusätzlich noch ein paar informelle Notizen ein (Gips bevorzugt in
Weiß / Gelb / Blau, gerne etwas fester gewickelt oder so etwas).
Zufällig stellt Abteilung B fest, dass der betreffende Patient der
Schwager von Chefarzt Prof. Dr. Sowieso ist und deshalb ... (den Rest
möge sich der geneigte Leser denken). Diese wichtige Information muss
natürlich sofort in die informellen Notizen.
Da die Notizfunktion eigentlich nur als nettes Gimmick gedacht, von den
Anwendern aber gerne benutzt wird, muss an dieser Stelle die
Entscheidung getroffen werden, welche Information nun wichtiger ist ;-)
Paul Werkowitz
> Hallo Paul,
>
>> anders machen, wenn's geht? Gib mal ein Szenario, wo man das das
>> vermeiden sollte, und insbesondere interessiert mich, warum die
>> Alternative besser ist.
>
> jeweiligen Datensatz sperrren, um so grösser wird die
> Wahrscheinlichkeit, dass andere Benutzer, die den selben Datensatz
> bearbeiten wollen, warten müssen, bis er endlich mal wieder freigegeben
> wird. In dieser Zeit müssen sie immer wieder mal versuchen, auf diesen
> Datensatz zuzugreifen um zu sehen, ob er immer noch gesperrt oder
> vielleicht jetzt doch schon frei ist.
Korrekt. Aber wenn wir annehmen, dass die MA in der Zeit, wo ein Satz
gesperrt ist, was anderes tun können, ist das zwar immer noch ein
Nachteil, aber akzeptabel, da die Vorteile gegenüber einer nachträglich
auftretenden Kollisionsbehandlung überwiegen. Im übrigen bleibt es ein
wiklich seltener Fall. "Normalerweise" arbeiten die Leute an
unterschiedlichen Sachen.
>
> Wenn die Anwendung ein solches pessimistisches Sperren nicht unbedingt
> erfordert, dann ist dieses pessimistisches Sperrverfahren absolut
> kontraproduktiv.
Nein, IMHO nicht. Zum x-ten Male: Es ist besser, Probleme zu vermeiden
als im Nachhnein zu behandeln. Durch das Sperren entstehen Nachteile,
die optimistic Locking nicht hat - klar soweit. Aber umgekehrt auch. Die
Nachbehandlung von Konflikten ist nicht trivial (jetzt nicht so sehr
technisch gesehen, sondern eher durch den Benutzer. Siehe mein
Storno-Beispiel). Man muss überlegen, welche Vorteile einem wichtiger
als die damit verbundenen Nachteile sind.
>
> Man muss schon sehr lange und sehr gründlich nachdenken, bis einem ein
> konkreter Anwendungsfall einfällt, der solch pessimistische Sperren
> wirklich unumgänglich notwendig macht. Ich habe Dich ja schon mal
> gefragt, ob Dir auf Anhieb ein solcher Anwendungsfall einfällt. Die
> Antwort darauf bist Du bisher schuldig geblieben.
>
Jo, und ich kann dir auch weiterhin keines geben, weil es das IMHO nicht
gibt. Pessimistische Sperren sind wahrscheinlich niemals *wirklich*
notwendig. Man kann alles immer irgendwie anders machen. Die Frage ist,
ob man das immer will.
Grüße - Paule
Paul Werkowitz
> Peer Schlephack wrote:
> ich bin zwar nicht der Peter, aber es gibt keine "gute Lösung allgemein".
> Ein pessimistisches Sperren braucht man z.B. in Reservierungssystemen.
Zum Beispiel dort ist es sinnvoll.
> Ein
> optimistisches Sperren sollte so oft wie möglich anstelle eines
> pessimistischen Sperrens angewandt werden. Man kann durch eine Vielzahl von
> "Tricks" auch die Kollisionsrate reduzieren. Dazu zählt z.B. das Update nur
> der Felder, die wirklich geändert wurden. Bei organisatorischer Trennung der
> Aufgabengebiete der Mitarbeiter gibt es in diesem Falle trotz fehlender
> pessimistischer Sperre bei der Bearbeitung des gleichen Datensatzes keine
> Konflikte.
Unter dieser Voraussetzung gibt es auch mit Sperrmechanismen keine
Probleme. Du musst einfach unterschiedliche Sperren für die disjunkten
Teilbereiche vorsehen.
Die interessantere Frage ist doch aber, was wir im Konfliktfall tun.
Wenn wirklich 2 Leute das gleiche Feld verändert haben.
Grüße - Paule
Sascha Münch
Peter Götz schrieb:
>> welche Lösung hälst du denn jetzt für gut Peter?
>
> Es gibt nicht die gute Lösung.
ACK
> 1.) Zugriffe nach dem Prinzip "wer zuletzt speichert, hat gewonnen".
> Dies stellt die geringsten Anforderungen in Sachen
> Mehrbenutzerkonflikte.
> Beispiel wäre eine Bestandverwaltung in einem Lager.
> Benutzer A gibt einen Lagerzugang ein, addiert damit
> zum bisherigen Bestand die neue Menge hinzu und
> speichert.
> Benutzer B gibt eine Lagerentnahme ein und subtrahiert
> damit vom bisherigen Bestand die entnommene Menge.
>
> In welcher Reihenfolge die Zugänge und Entnahmen
> gespeichert werden ist völlig egal.
Nöö. Lagerbestand 5, Zugang 10, Abgang 7. Da kann man zu folgenden
Ergebnissen kommen: 15 oder -2, da ja beide vom Lagerbstand 5 aus ein
Update gemacht haben. (Kleine Randbemerkung: bei Lagerbeständen würde
ich evtl. mit einer Tabelle Bewegungsdaten arbeiten)
> 2.) Zugriffe bei denen der Benutzer informiert werden muss,
> falls seit Beginn seiner Änderungseingabe sein Datensatz
> durch einen anderen Benutzer verändert worden ist.
Was ich für Stammdaten noch akzeptable halte, aber bei Dokumenten
(Rechnungen, Anfragen, CRM-Aktivitäten, etc) nicht meinem Kunden antuen
würde.
> 3.) Zugriffe bei denen vom Beginn der Änderungseingabe bis
> zum Ende der Ausführung des UpdateCommands der
> akt. Datensatz durch andere Benutzer nicht verändert
> werden darf.
>
> Dieser Fall lässt sich mit dem von mir nun schon mehrfach
> beschriebenen Zeitfeld (Now + gewünschte Sperrzeit)
Wobei ich diesen Timer persönlich nicht gut finde, da bei mir die
Bearbeitung eines Datensatzes durchaus mehrere Rückfragen und Telefonate
bedeuten kann. Aber da kann man ja auch vor Ablauf einfach mal eine
Rückfrage stellen.
Aber einen weiteren Punkt würde ich noch gerne hinzufügen:
4.) Lock-Mechanismen des DBMS.
Im Rahmen einer Transaktion sollte ein DBMS selber dafür sorgen,
dass die Daten konsistent bleiben. Die ist aber eher für
automatisierte Buchungsvorgänge gedacht und geeigent als für die
Anbindung eines Frontends. Aber natürlich könnte man auch diese sich
hier zu nutze machen.
Deadlocks lassen sich hier ganz gut vermeiden, wenn man in seinen
automatisierten Prozessen ein paar Grundregeln beachtet: z.B.: immer
erst Kopf und dann Detailtabellen ansprechen.
Ich für meinen Teil habe mich für die 3 (ohne Timer) und 4 entschieden
um sicherzustellen, dass die Daten konsistent bleiben. Wobei die 3 nur
für den FrontEnd-Betrieb genutzt wird und die 4 für die automatisierten
Prozesse.
CU
Sascha
Sascha Münch
Peter Götz schrieb:
>> Ehrlich gesagt..... da wäre mir exklusives Sperren lieber. Da muss
> ich
>> vielleicht bisschen warten, aber ich bin sicher, nichts zu verlieren.
>
> In einem grossen Unternehmen sollen also beispielsweise einige tausend
> Mitarbeiter einen grossen Teil ihrer Arbeitszeit damit verbringen auf
Ist doch besser, als wenn mehrere Mitarbeiter den selben Mist eingeben,
und hinterher erfahren, dass ein Kollege bereits dieses Dokument
bearbeitet hat, evtl. sogar schon verbucht hat.
> Wer soll das bezahlen, wer hat soviel Geld, wer ....?
Zahllauf nochmal macht? Ja... Super wer soll das bezahlen?
Nur mal so am Rande: SAP blockt auch das komplette Dokument, wenn jemand
im Änderungsmodus ist. Bin zwar kein Freund von der Software aus Polen,
aber bei den Kunden scheint man es bezahlen zu können...
CU
Sascha
Paul Werkowitz
> Hallo Paul,
>
> Paul Werkowitz schrieb:
> Da die Notizfunktion eigentlich nur als nettes Gimmick gedacht, von den
> Anwendern aber gerne benutzt wird, muss an dieser Stelle die
> Entscheidung getroffen werden, welche Information nun wichtiger ist ;-)
>
Hallo Klaus,
und genau das geht nicht! Unsere Anwender würden sich bedanken, wenn
eine Krankenschwester, die eine Routineaufnahme durchführt, entscheiden
sollte, welche Informationen im Konfliktfall übernommen und welche
ignoriert werden sollten. Diese Entscheidung kann und vor allem *will*
sie nicht treffen. Im Gegenteil: Es wird gefordert, dass alles das, was
eingegeben wird, auch im System erscheint. Ganz einfach.
Und aus genau diesem Grunde muss das Design so sein, dass solche
Situationen, in denen es etwas zu entscheiden gibt, nicht auftreten können.
Grüße - Paule
Klaus P. Pieper
Paul Werkowitz schrieb:
>
> und genau das geht nicht! Unsere Anwender würden sich bedanken, wenn
> eine Krankenschwester, die eine Routineaufnahme durchführt, entscheiden
> sollte, welche Informationen im Konfliktfall übernommen und welche
> ignoriert werden sollten. Diese Entscheidung kann und vor allem *will*
> sie nicht treffen. Im Gegenteil: Es wird gefordert, dass alles das, was
> eingegeben wird, auch im System erscheint. Ganz einfach.
mach doch der Ullallalla Schmidt mal so einen Vorschlag, da wird sie
sicher gleich ein Potential zur Kostensenkung entdecken ;-) Nee Spaß
beiseite, der Beitrag war (natürlich) ironisch gemaint, deshalb ja der
Smiley.
Peter Fleischer
...
> Nöö. Lagerbestand 5, Zugang 10, Abgang 7. Da kann man zu folgenden
> Ergebnissen kommen: 15 oder -2, da ja beide vom Lagerbstand 5 aus ein
> Update gemacht haben. (Kleine Randbemerkung: bei Lagerbeständen würde
> ich evtl. mit einer Tabelle Bewegungsdaten arbeiten)
Sascha,
Ergebnisse von Ausdrücken sollte man niemals als "Stammwerte" in einer
Datenbank speichern.
>> 2.) Zugriffe bei denen der Benutzer informiert werden muss,
>> falls seit Beginn seiner Änderungseingabe sein Datensatz
>> durch einen anderen Benutzer verändert worden ist.
>
> Was ich für Stammdaten noch akzeptable halte, aber bei Dokumenten
> (Rechnungen, Anfragen, CRM-Aktivitäten, etc) nicht meinem Kunden
> antuen würde.
Üblicher weise werden ja Bewegungsdaten nicht verändert und nar als
"Protokoll" abgelegt. Da kann so etwas nicht passieren.
>> 3.) Zugriffe bei denen vom Beginn der Änderungseingabe bis
>> zum Ende der Ausführung des UpdateCommands der
>> akt. Datensatz durch andere Benutzer nicht verändert
>> werden darf.
>>
>> Dieser Fall lässt sich mit dem von mir nun schon mehrfach
>> beschriebenen Zeitfeld (Now + gewünschte Sperrzeit)
>
> Wobei ich diesen Timer persönlich nicht gut finde, da bei mir die
> Bearbeitung eines Datensatzes durchaus mehrere Rückfragen und
> Telefonate bedeuten kann. Aber da kann man ja auch vor Ablauf einfach
> mal eine Rückfrage stellen.
Da hast du das Prinzip nicht verstanden. Der "Blockierer" verlängert bei
Bedarf den Freigabezeitpunkt. Solange die Anwendung bedient wird, setzt sie
vor Ablauf der "Blockierfrist" diese hoch. Erst, wenn der Bediener nichts
mehr macht, wird nachgefragt und nur bei entsprechender Antwort des
Bedieners die "Blockierfrist" hochgesetzt. Wenn der Bediener das nicht
macht, weil er Pause macht, oder der PC abgestützt ist, dann hat er Pech und
muss die uznvollendete Arbeit nochmals machen.
> Aber einen weiteren Punkt würde ich noch gerne hinzufügen:
>
> 4.) Lock-Mechanismen des DBMS.
> Im Rahmen einer Transaktion sollte ein DBMS selber dafür sorgen,
> dass die Daten konsistent bleiben. Die ist aber eher für
> automatisierte Buchungsvorgänge gedacht und geeigent als für die
> Anbindung eines Frontends. Aber natürlich könnte man auch diese
> sich hier zu nutze machen.
> Deadlocks lassen sich hier ganz gut vermeiden, wenn man in seinen
> automatisierten Prozessen ein paar Grundregeln beachtet: z.B.:
> immer erst Kopf und dann Detailtabellen ansprechen.
Dieses Prinzip ist aber bei Löschvorgängen nicht realisierbar, da es zu
Inkonsistenzen (Comntraint-Fehlern) führt.
> Ich für meinen Teil habe mich für die 3 (ohne Timer) und 4 entschieden
> um sicherzustellen, dass die Daten konsistent bleiben. Wobei die 3 nur
> für den FrontEnd-Betrieb genutzt wird und die 4 für die
> automatisierten Prozesse.
Wie soll (3) ohne Timer funktionieren? Und (4) geht auch nur für bestimmte
Abläufe.
Peter
Peter Fleischer
...
> Die interessantere Frage ist doch aber, was wir im Konfliktfall tun.
> Wenn wirklich 2 Leute das gleiche Feld verändert haben.
Paule,
trenne dich mal vom PC und analysiere mal das Leben in einem Büro:
- Zwei Mitarbeiter bestellen das nur einmal benötigte Material.
- Zwei Mitarbeiter führen Listen zum gleichen Sachverhalt, aktualisieren
diese selbständig und geben dann Auskunft oder nutzen sie (z. B.
Preislisten).
- Der Chef trifft regelmäßig Festlegungen, die umzusetzen sind und alte
Festlegungen außer Kraft setzen. Ein Mitarbeiter fehlt (z. B. wegen
kurzfristiger Delegierung) und arbeitet wegen mangelnder Kenntnis der neuen
Festlegung nach der alten Festlegung, was vielleicht zu Fehltentscheidungen
und Verlusten für das Unetrnehemn führt.
Solche Konflikte können nur die Mitarbeiter anhand konkreter Regelungen
zielsicher treffen. Und genau so ist auch die Konfliktlösung bei
Konkurenzfehlern in den Programmen zu gestalten. Die Mitarbeiter müssen
entscheiden und sollten nicht so sehr entmündigt werden. Das größte
Augenmerk ist auf die Informationesbereitstellung durch das Programm zu
richten, damit sie auch zielsicher entscheiden können.
Peter
Klaus P. Pieper
Peter Fleischer schrieb:
> Sascha Münch wrote:
> ...
>
>>Nöö. Lagerbestand 5, Zugang 10, Abgang 7. Da kann man zu folgenden
>>Ergebnissen kommen: 15 oder -2, da ja beide vom Lagerbstand 5 aus ein
>>Update gemacht haben. (Kleine Randbemerkung: bei Lagerbeständen würde
>>ich evtl. mit einer Tabelle Bewegungsdaten arbeiten)
>
> Sascha,
> Ergebnisse von Ausdrücken sollte man niemals als "Stammwerte" in einer
> Datenbank speichern.
bei einer Lagerverwaltung ist es aus Performancegründen häufig
notwendig, einmal die komplette Beleghistorie in einem Lagerjournal
abzulegen, den aktuell verfügbaren und reservierten Bestand pro Artikel
bzw. Ausführung aber zusätzlich in einer eigenen Tabelle. In ganz
einfachen Systemen sogar im Artikelstammsatz selbst.
Der Grund ist ganz einfach: wenn man die eigentlich redundanten
aktuellen Daten bei jeder Abfrage durchsuchen müsste, dauerte das bei
einem umfangreichen Lagerjournal einfach zu lange.
Übrigens schleichen sich auch bei teuren & komplexen Großsystemen an
dieser Stelle immer mal wieder (geringe) Abweichungen zwischen den
Bewegungsdaten und den aktuellen Daten ein. Deshalb werden die aktuellen
Daten häufig aus den Bewegungsdaten in einem Batch in der Nacht neu
ermittelt.
>
>>Aber einen weiteren Punkt würde ich noch gerne hinzufügen:
>>
>>4.) Lock-Mechanismen des DBMS.
>> Im Rahmen einer Transaktion sollte ein DBMS selber dafür sorgen,
>> dass die Daten konsistent bleiben. Die ist aber eher für
>> automatisierte Buchungsvorgänge gedacht und geeigent als für die
>> Anbindung eines Frontends. Aber natürlich könnte man auch diese
>> sich hier zu nutze machen.
>> Deadlocks lassen sich hier ganz gut vermeiden, wenn man in seinen
>> automatisierten Prozessen ein paar Grundregeln beachtet: z.B.:
>> immer erst Kopf und dann Detailtabellen ansprechen.
>
> Dieses Prinzip ist aber bei Löschvorgängen nicht realisierbar, da es zu
> Inkonsistenzen (Comntraint-Fehlern) führt.
Beim Löschen erfolgt der Vorgang genau umgekehrt. Erst die Details, dann
den Kopf.
Peter Fleischer
...
> notwendig, einmal die komplette Beleghistorie in einem Lagerjournal
> abzulegen, den aktuell verfügbaren und reservierten Bestand pro
> Artikel bzw. Ausführung aber zusätzlich in einer eigenen Tabelle. In
> ganz einfachen Systemen sogar im Artikelstammsatz selbst.
Klaus,
so etwas wird gemacht, mit dem Unterschie, dass solch ein Feld nicht durch
den Bediener änderbar ist, sondern automatisch neu berechnet wird, wenn ein
Beleghistorie-Datensatz hinzugefügt wird. Da kann es keine Probleme geben,
da solche Vorgänge in Transaktionen ausgeführt werden.
> Der Grund ist ganz einfach: wenn man die eigentlich redundanten
> aktuellen Daten bei jeder Abfrage durchsuchen müsste, dauerte das bei
> einem umfangreichen Lagerjournal einfach zu lange.
>
> Übrigens schleichen sich auch bei teuren & komplexen Großsystemen an
> dieser Stelle immer mal wieder (geringe) Abweichungen zwischen den
> Bewegungsdaten und den aktuellen Daten ein. Deshalb werden die
> aktuellen Daten häufig aus den Bewegungsdaten in einem Batch in der
> Nacht neu ermittelt.
Das hat nichts mit häufig und komplex zu tun, sondern ist ein
Sicherheitsaspekt. Bei Systemfehlern kann es schnell zu Inkonsistenzen
kommen, besonderns bei komplexen und verteilt arbeitenden Systemen. Das
beste Beispiel ist das Bankwesen. Jede Nach wird ein Buchungslauf
durchgeführt, der die Bewegungsdaten des letzten Tages in den
Aggregatfeldern aufrechnet. Recherchen zum aktuellen Tage dauern immer etwas
länger und basieren auf dem Stand des Vortages und der Analyse der
Bewegungsdaten des aktuellen Tages. Diese Technologie sichert immer, das zu
jedem Zeitpunkt die Daten fehlerfrei mit recht geringem Aufwand
wiederhersgestellt werden können.
...
>>> 4.) Lock-Mechanismen des DBMS.
>>> Im Rahmen einer Transaktion sollte ein DBMS selber dafür sorgen,
>>> dass die Daten konsistent bleiben. Die ist aber eher für
>>> automatisierte Buchungsvorgänge gedacht und geeigent als für die
>>> Anbindung eines Frontends. Aber natürlich könnte man auch diese
>>> sich hier zu nutze machen.
>>> Deadlocks lassen sich hier ganz gut vermeiden, wenn man in seinen
>>> automatisierten Prozessen ein paar Grundregeln beachtet: z.B.:
>>> immer erst Kopf und dann Detailtabellen ansprechen.
>>
>> Dieses Prinzip ist aber bei Löschvorgängen nicht realisierbar, da es
>> zu Inkonsistenzen (Comntraint-Fehlern) führt.
>
> Beim Löschen erfolgt der Vorgang genau umgekehrt. Erst die Details,
> dann den Kopf.
Hinzu kommt noch die Reihenfolge! Aktualisieren muss immer nach Hinzufügen
folgen und Löschen darf erst am schluss gemacht werden!
Peter
Klaus P. Pieper
Peter Fleischer schrieb:
> Klaus P. Pieper wrote:
> ...
>
>>bei einer Lagerverwaltung ist es aus Performancegründen häufig
>>notwendig, einmal die komplette Beleghistorie in einem Lagerjournal
>>abzulegen, den aktuell verfügbaren und reservierten Bestand pro
>>Artikel bzw. Ausführung aber zusätzlich in einer eigenen Tabelle. In
>>ganz einfachen Systemen sogar im Artikelstammsatz selbst.
>
> Klaus,
> so etwas wird gemacht, mit dem Unterschie, dass solch ein Feld nicht durch
> den Bediener änderbar ist, sondern automatisch neu berechnet wird, wenn ein
> Beleghistorie-Datensatz hinzugefügt wird. Da kann es keine Probleme geben,
> da solche Vorgänge in Transaktionen ausgeführt werden.
da hast du natürlich Recht.
Paul Werkowitz
dem kann ich ganz und gar nicht zustimmen.
Wann warst du zum letzten Mal beim Arzt oder Zahnarzt? Welchen Eindruck
hattest du von den Helferinnen, was die Beherrschung ihrer EDV angeht?
Während das in Privatpraxen noch einigermaßen funktioniert, sieht es in
großen Häusern schon anders aus. Nicht nur, dass die Leute dort sich mit
Medizin und nicht mit EDV befassen wollen, weigern sich gerade die
einfacheren Ränge durch die Bank, Entscheidungen zu treffen. Eine solche
könnte nämlich auch mal falsch sein, und dann gibts gleich eins auf die
Mütze. Die Schwester sagt mit Recht, dass sei nicht ihre Aufgabe, und
bei der Vergütung, die sie bekommt, stimme ich ihr voll zu.
Hinzu kommt der Effekt, dass die Leute, die Daten eingeben, nicht
unbedingt diejenigen sind, die nachher die Abrechnung machen. Den
Eingebenden ist deswegen mitunter die Datenqualität völlig wurscht.
Tritt also ein Konflikt auf, drücken die Escape und lassens gut sein.
Sry - das ist leider nun mal die Praxis.
Dein dargestelltes Szenario ist wünschenswert, aber realitätsfremd.
Grüße - Paule
Peter Götz
> dem kann ich ganz und gar nicht zustimmen.
Ich vermute mal, dir kann jemand beweisen, dass etwas rot ist und Du
wirst trotzdem weiterhin behaupten, dass es blau ist.
> Wann warst du zum letzten Mal beim Arzt oder Zahnarzt? Welchen
Eindruck
> hattest du von den Helferinnen, was die Beherrschung ihrer EDV
angeht?
Ich habe vor einigen Jahren mit meinem damaligen Team in einer grossen
Kreisklinik einige hundert PCs inkl. System u. Software installiert und
u.a. auch beim Customizing von SAP mitgewirkt. Dabei hatte ich
keineswegs den Eindruck gewonnen, dass die Mitarbeiter dieser Klinik in
Sachen EDV besonders unfähig oder gar uninteressiert gewesen wären. Das
Gegenteil war der Fall.
> Während das in Privatpraxen noch einigermaßen funktioniert, sieht es
in
> großen Häusern schon anders aus. Nicht nur, dass die Leute dort sich
mit
> Medizin und nicht mit EDV befassen wollen, weigern sich gerade die
> einfacheren Ränge durch die Bank, Entscheidungen zu treffen.
s.oben:
Meine Erfahrungen sind da ganz andere. Egal ob Ärzte, medizinisches
Hilfspersonal, Apotheker oder Verwaltungspersonal, alle waren sehr
aufgeschlossen und in der Lage in recht kurzer Zeit zu verstehen, wie
sie mit ihrem neuen System effizient arbeiten können.
Ich erlebe aber immer wieder sogenannte EDV- oder IT-Experten, die sich
selbst für die Krone der Schöpfung halten und glauben, jeden der sich
nicht ausschliesslich mit Datenverarbeitung beschäftigt nicht ernst
nehmen zu müssen.
Wenn ein Benutzer mit einer Software nicht zurechtkommt, dann liegt es
nur selten an diesem Benutzer, sondern meist an unfähigen
Programmierern und Leuten die diesen Benutzer geschult haben.
> Eine solche
> könnte nämlich auch mal falsch sein, und dann gibts gleich eins auf
die
> Mütze. Die Schwester sagt mit Recht, dass sei nicht ihre Aufgabe, und
> bei der Vergütung, die sie bekommt, stimme ich ihr voll zu.
Mir fällt kaum ein Beruf ein, bei dem der einzelne nicht ständig
irgendwelche Entscheidungen zu treffen hätte. Wäre es anders, müsste
man einen Beruf ja nicht erst erlernen. Es gibt für jede Art von
Tätigkeit gewisse Vorgaben und Regeln.
Lassen sich für eine bestimmte Situation alle möglichen Entscheidungen
durch exakt definierte Regeln und Grenzwerte festlegen, dann ist es
kein Problem solche Entscheidungen zu automatisieren, sprich in
konkreten Programmcode umsetzen. In den verbleibenden Fällen bleibt nur
der Weg, erforderliche Entscheidungen von Menschen treffen zu lassen.
> Hinzu kommt der Effekt, dass die Leute, die Daten eingeben, nicht
> unbedingt diejenigen sind, die nachher die Abrechnung machen. Den
> Eingebenden ist deswegen mitunter die Datenqualität völlig wurscht.
Deswegen wird jede vernünftige Software dafür Sorge tragen, dass Fehler
bei der Datenerfassung so weit als möglich ausgeschlossen werden. Das
kann u.a. durch Plausibilitätsprüfungen und weitere Kontrollmechanismen
realisiert werden.
> Tritt also ein Konflikt auf, drücken die Escape und lassens gut sein.
> Sry - das ist leider nun mal die Praxis.
Ich bin nun seit gut 40 Jahren in der Datenverarbeitung tätig, aber mir
sind derart uninteressierte und Deiner Beschreibung nach völlig
unfähige Benutzer in meiner Berufspraxis nur höchst selten begegnet.
> Dein dargestelltes Szenario ist wünschenswert, aber realitätsfremd.
Ich denke, Du solltest das, was Du selbst für Realität hälts, mal ein
wenig selbstkritisch überprüfen. Schon Deine Art, EDV-Benutzer für
grundsätzlich unfähig zu halten, stimmt mich sehr skeptisch.
Paul Werkowitz
> Hallo Paul,
>
Hallo Peter,
zunächst einmal vielen Dank für deine Zeit, dich mit den Fragestellungen
auseinanderzusetzen. Allerdings bewegen mich einige Äußerungen dann
doch dazu, hier nicht mehr weiter machen zu wollen. Für mich also
hiermit EOD.
>> dem kann ich ganz und gar nicht zustimmen.
>
> Ich vermute mal, dir kann jemand beweisen, dass etwas rot ist und Du
> wirst trotzdem weiterhin behaupten, dass es blau ist.
>
Überleg mal, was du damit unterstellst. Allein das reicht normalerweise
fürs killfile.
[snip]
>> Tritt also ein Konflikt auf, drücken die Escape und lassens gut sein.
>> Sry - das ist leider nun mal die Praxis.
>
> Ich bin nun seit gut 40 Jahren in der Datenverarbeitung tätig, aber mir
> sind derart uninteressierte und Deiner Beschreibung nach völlig
> unfähige Benutzer in meiner Berufspraxis nur höchst selten begegnet.
>
Der Auftrggeber wünscht mittlerweile die Nachvollziehbarkeit ALLER
Eingaben, Änderungen und Löschungen um Probleme der Datenqualität auf
die Eingebenden zurückführen zu können. Ich hoffe mal, nur damit diese
eine zusätzliche Schulung bekommen.....
>> Dein dargestelltes Szenario ist wünschenswert, aber realitätsfremd.
>
> Ich denke, Du solltest das, was Du selbst für Realität hälts, mal ein
> wenig selbstkritisch überprüfen. Schon Deine Art, EDV-Benutzer für
> grundsätzlich unfähig zu halten, stimmt mich sehr skeptisch.
Zunächst mal sind das meine Erfahrungen. Du hast andere, auch ich habe
andere, aber hier ist es nun mal so. Insofern ist das schon Relität.
Realität heißt nicht, dass es immer und überall so sein muss.
Selbstverständlich halte ich nicht alle EDV-Benutzer für grundsätzlich
unfähig. Du neigst hier - und übrigends auch in deinen früheren
Beiträgen - etwas zur Pauschalisierung. Allerdings haben wir in der
konkreten Anwendung da schon so einige Kandidaten.....
Und daher wird die SW so entwickelt, dass möglichst wenig Entscheidungen
zu treffen sind. Das Vermeiden von Kollisionsbehandlungen gehört
definitv dazu. Den Preis der Recordsperre nehme ich in Kauf.
Ich gehe mal auf Grund der Historie dieses Threads davon aus, dass ich
nicht der Einzige bin, der dies so favorisiert.
Grüße - Paule
Sascha Münch
Paul Werkowitz schrieb:
> Peter Götz schrieb:
>>> Tritt also ein Konflikt auf, drücken die Escape und lassens gut sein.
>>> Sry - das ist leider nun mal die Praxis.
>>
>> Ich bin nun seit gut 40 Jahren in der Datenverarbeitung tätig, aber mir
>> sind derart uninteressierte und Deiner Beschreibung nach völlig
>> unfähige Benutzer in meiner Berufspraxis nur höchst selten begegnet.
Glücklicher! Mir begegenen im Moment Leute in der Buchhaltung die mir
noch nicht mal erklären können, wie Sie ein handvoll Steuersätze buchen,
die mir das SAP um die Ohren haut. Sie können mir nur sagen, dass die
-16% die ich anzeige "irgendwie" falsch sind...
> Der Auftrggeber wünscht mittlerweile die Nachvollziehbarkeit ALLER
> Eingaben, Änderungen und Löschungen um Probleme der Datenqualität auf
Jo Changelog auf Feldebene. Ganz toll um die Datenbank zu füllen... :-(
>> wenig selbstkritisch überprüfen. Schon Deine Art, EDV-Benutzer für
>> grundsätzlich unfähig zu halten, stimmt mich sehr skeptisch.
>
> Zunächst mal sind das meine Erfahrungen. Du hast andere, auch ich habe
> andere, aber hier ist es nun mal so. Insofern ist das schon Relität.
> Realität heißt nicht, dass es immer und überall so sein muss.
Meine Realität sieht so aus, dass im Osten noch ein ziemlicher
IT-Lern-Bedarf besteht. Wohingegen ein Kollege aus Leipzig bei seinem
Kunden etliche mit reichlich Know-How und Interesse an IT vorgefunden hatte.
> zu treffen sind. Das Vermeiden von Kollisionsbehandlungen gehört
> definitv dazu. Den Preis der Recordsperre nehme ich in Kauf.
In meinem Fall hörte ich sogar mal: "och, das ist ja gut, dass uns die
Software sagt wenn da schon ein Kollege dran ist, dann brauche ich es ja
nicht mehr zu machen ...."
> Ich gehe mal auf Grund der Historie dieses Threads davon aus, dass ich
> nicht der Einzige bin, der dies so favorisiert.
Nie nicht ;-)
CU
Sascha
Sascha Münch
Peter Fleischer schrieb:
> Sascha Münch wrote:
> ....
>> Nöö. Lagerbestand 5, Zugang 10, Abgang 7. Da kann man zu folgenden
>> Ergebnissen kommen: 15 oder -2, da ja beide vom Lagerbstand 5 aus ein
> Ergebnisse von Ausdrücken sollte man niemals als "Stammwerte" in einer
> Datenbank speichern.
Da gebe ich dir recht, allerdings habe ich deinen Namensvetter so
verstanden, dass er dies machen wollte. Wenn man hier Performance will,
dann kann man die Daten ja notfalls durch einen Aggreatlauf schicken
(nachts/wöchentlich/manatlich/...), wie in einem andern Posting beschrieben.
>> Wobei ich diesen Timer persönlich nicht gut finde, da bei mir die
>> Bearbeitung eines Datensatzes durchaus mehrere Rückfragen und
>> Telefonate bedeuten kann. Aber da kann man ja auch vor Ablauf einfach
>> mal eine Rückfrage stellen.
>
> Da hast du das Prinzip nicht verstanden. Der "Blockierer" verlängert bei
> Bedarf den Freigabezeitpunkt. Solange die Anwendung bedient wird, setzt sie
> vor Ablauf der "Blockierfrist" diese hoch. Erst, wenn der Bediener nichts
> mehr macht, wird nachgefragt und nur bei entsprechender Antwort des
> Bedieners die "Blockierfrist" hochgesetzt. Wenn der Bediener das nicht
> macht, weil er Pause macht, oder der PC abgestützt ist, dann hat er Pech und
> muss die uznvollendete Arbeit nochmals machen.
Ok, das automatische Verlängern hatte ich nicht bedacht. Ist zwar schon
besser, aber gefallen tut mir der Timer immer noch nicht so richtig.
Fällt aber eher unter persönliches Unwohlbefinden, als unter einen
rational erklärbaren Grund.
>> 4.) Lock-Mechanismen des DBMS.
>> Im Rahmen einer Transaktion sollte ein DBMS selber dafür sorgen,
>> dass die Daten konsistent bleiben. Die ist aber eher für
>> automatisierte Buchungsvorgänge gedacht und geeigent als für die
>> Anbindung eines Frontends. Aber natürlich könnte man auch diese
>> sich hier zu nutze machen.
>> Deadlocks lassen sich hier ganz gut vermeiden, wenn man in seinen
>> automatisierten Prozessen ein paar Grundregeln beachtet: z.B.:
>> immer erst Kopf und dann Detailtabellen ansprechen.
>
> Dieses Prinzip ist aber bei Löschvorgängen nicht realisierbar, da es zu
> Inkonsistenzen (Comntraint-Fehlern) führt.
On Delete cascade? Da kümmert sich derjenige um die Constraints der es
besser kann als ich. Abgesehen davon habe ich keine Löschvorgänge die
ich beachten müsste. Aus Revisionsgründen kann maximal "not active"
gesetzt werden aber nichts gelöscht werden, daher habe ich mich mit
Löschen nicht wirklich intensiv beschäftigt.
>> Ich für meinen Teil habe mich für die 3 (ohne Timer) und 4 entschieden
>> um sicherzustellen, dass die Daten konsistent bleiben. Wobei die 3 nur
>> für den FrontEnd-Betrieb genutzt wird und die 4 für die
>> automatisierten Prozesse.
>
> Wie soll (3) ohne Timer funktionieren? Und (4) geht auch nur für bestimmte
> Abläufe.
Schrieb ich zu (4) ebenfalls.
(3) ohne Timer funktioniert so, dass Stamp_Date und Stamp_User verwendet
wird und die Anwendung beides selber wieder löschen muss. Für den
Chrash-Fall gibt es in einer Admin-Applikation noch einen "Remove Locks
from User x" Button.
Wenn der Admin dann zu genervt wird, hat man einen guten Indikator für
die Stabilität des Netzwerkes oder der Software... Bislang war es ein
gutes Vorwarnzeichen für den gemächlichen Abgang eines Switches.
Wenn ich das so schreibe, kommt mir noch der Gedanke an eine
Kombination: (3) mit Timer und Stamp_User. Dadurch könnte man der langen
Bearbeitungszeit ihren Tribut zollen und 10 Minuten ansetzen. Stürzt die
Kiste in der Zeit ab und wird neu gebootet, kann der User selber wieder
rein, weil er ja selber gesperrt hat. Setzt natürlich reale
Useranmeldungen vorraus und nicht annonyme "den kennt jeder" User.
Da muss ich aber nochmal in Ruhe drüber nachdenken.
CU
Sascha
Peter Fleischer
...
>> ... Aus Revisionsgründen kann maximal "not active"
> gesetzt werden aber nichts gelöscht werden, daher habe ich mich mit
> Löschen nicht wirklich intensiv beschäftigt.
Sascha,
das Prinzip finde ich sehr gut. Es lässt leichtere Refresh-Algorithmen zu,
da nimals Datensätze gelöscht werden.
>>> Ich für meinen Teil habe mich für die 3 (ohne Timer) und 4
>>> entschieden um sicherzustellen, dass die Daten konsistent bleiben.
>>> Wobei die 3 nur für den FrontEnd-Betrieb genutzt wird und die 4 für
>>> die automatisierten Prozesse.
>>
>> Wie soll (3) ohne Timer funktionieren? Und (4) geht auch nur für
>> bestimmte Abläufe.
>
> Schrieb ich zu (4) ebenfalls.
> (3) ohne Timer funktioniert so, dass Stamp_Date und Stamp_User
> verwendet wird und die Anwendung beides selber wieder löschen muss.
> Für den Chrash-Fall gibt es in einer Admin-Applikation noch einen
> "Remove Locks from User x" Button.
> Wenn der Admin dann zu genervt wird, hat man einen guten Indikator für
> die Stabilität des Netzwerkes oder der Software... Bislang war es ein
> gutes Vorwarnzeichen für den gemächlichen Abgang eines Switches.
Solange keine Außendienstmitarbeiters über das Internet zugreifen, mag das
vielleicht noch gehen. Aber wie willst du den Admin für die Qualität der
telekom verantwortlich machen. Oder was machst du, wenn der Admin
Arbeitsschluss oder Urlaub hat oder krank ist. Das ist mir alles zu
unsicher.
> Wenn ich das so schreibe, kommt mir noch der Gedanke an eine
> Kombination: (3) mit Timer und Stamp_User. Dadurch könnte man der
> langen Bearbeitungszeit ihren Tribut zollen und 10 Minuten ansetzen.
> Stürzt die Kiste in der Zeit ab und wird neu gebootet, kann der User
> selber wieder rein, weil er ja selber gesperrt hat. Setzt natürlich
> reale Useranmeldungen vorraus und nicht annonyme "den kennt jeder"
> User. ...
Ohne die User-Anmeldung geht auch keine Windows integrierte Sicherheit und
damit auch kein Zugriff. Alles andere kann Zuverlässigkeitsprobleme bringen,
wenn man es nicht richtig implementiert und sollte die absolute Ausnahme
sein, wenn es sich nicht vermeiden lässt.
Peter
Paul Werkowitz
>
>> Der Auftrggeber wünscht mittlerweile die Nachvollziehbarkeit ALLER
>> Eingaben, Änderungen und Löschungen um Probleme der Datenqualität auf
>
> Jo Changelog auf Feldebene. Ganz toll um die Datenbank zu füllen... :-(
>
Transaktion aufnehmen. Die XML-Texte werden komprimiert, zusätzlich
verschlüsselt und mit geeigneten Indexfeldern versehen in speziellen
Audit-Tabellen *getrennt* vom normalen Datenbestand abgelegt.
Grüße - Paule