Meinung der Experten!

11/09/2008 - 10:40 von Jafar | Report spam
Hallo Allerseits,

ich arbeite an einem Project, wo mehre Leute gleichzeitig an einem DB
arbeiten sollen und kommt vor, dass auf gleichen Datensatz zur gleichen Zeit
zugegriffen wird.
Ich habe mir vorgestellt, dass ich für meine Transactionen Isolation Level
snapshot oder besser READ UNCOMMITTED nehme.
Das ist meine erste Frage: ist meine Vorgehweise richtige oder gibts es
bessere?

Die andere Frage ist, wie ist es wenn ein Datensatz von einem Benutzer für
update gesperrt ist und anderer Benutzer ruft den Datensatz (weil read
uncommitted) auf und fàngt an, in Clint Formular was zu àndern (ohne zu
wissen, dass Datensatz gesperrt ist) und bei bei dem Abschicken der Änderung
was passiert wenn wir nehmen, dass der anderer User fertig mit update ist und
datensatz ist nicht mehr gesperrt.
Wie kann man diese Situation behandeln?
gibt es da eine Möglichkeit, dem zweiten Benutzer eine Mitteilung schicken,
nachdem eine Änderung von erstem bentzer durchgeführt wurde?

Vielen Dank
Hallo allerseits,

ich arbeite an einem Project, wo mehre Leute gleichzeitig an einem DB
arbeiten sollen und kommt vor, dass auf gleichen Datensatz zur gleichen Zeit
zugegriffen wird.
Ich habe mir vorgestellt, dass ich für meine Transactionen Isolation Level
snapshot oder besser READ UNCOMMITTED nehme.
Das ist meine erste Frage: ist meine Vorgehweise richtige oder gibts es
bessere?

Die andere Frage ist, wie ist es wenn ein Datensatz von einem Benutzer für
update gesperrt ist und anderer Benutzer ruft den Datensatz (weil read
uncommitted) auf und fàngt an, in Clint Formular was zu àndern (ohne zu
wissen, dass Datensatz gesperrt ist) und bei bei dem Abschicken der Änderung
was passiert wenn wir nehmen, dass der anderer User fertig mit update ist und
datensatz ist nicht mehr gesperrt.
Wie kann man diese Situation behandeln?
gibt es da eine Möglichkeit, dem zweiten Benutzer eine Mitteilung schicken,
nachdem eine Änderung von erstem bentzer durchgeführt wurde?

Vielen Dank
Jafar
 

Lesen sie die antworten

#1 Elmar Boye
11/09/2008 - 16:19 | Warnen spam
Hallo Jafar,

Jafar schrieb:
ich arbeite an einem Project, wo mehre Leute gleichzeitig an einem DB
arbeiten sollen und kommt vor, dass auf gleichen Datensatz zur gleichen Zeit
zugegriffen wird.
Ich habe mir vorgestellt, dass ich für meine Transactionen Isolation Level
snapshot oder besser READ UNCOMMITTED nehme.
Das ist meine erste Frage: ist meine Vorgehweise richtige oder gibts es
bessere?



An einem Beispiel verdeutlicht:
Du hast Deinem Chef gerade noch zum Monatsende eine Gehaltserhöhung
abgetrotzt, die er gleich bei Dir eintràgt.
Nun liest die Lohnbuchhaltung parallel Deine Daten für die Überweisung
ohne Sperre aus und kriegt so noch das alte angezeigt und überweist
den alten Betrag.

Frage: Beim wem beschwerst Du Dich?
Dem Chef, der Lohnbuchhaltung oder Dir selbst (dem Programmierer)?

Das (etwas konstruierte) Beispiel sollte zeigen, das ein
Zugriff mit READ UNCOMMITTED eine schlechte Idee ist.
Das sollte man niemals als Standard-Zugriffsmethode verwenden.
Bestenfalls kann man es mal verwenden wenn man eine Schàtzung
braucht, wo es auf die letzte Genauigkeit nicht ankommt.
(ich denke, beim Bankkonto möchte aber niemand nur geschàtzt werden)

Ähnliches gilt für eine Snapshot Isolation.
Die ist zwar insofern besser, als die Daten konsequent
von einem Zeitpunkt ab konsistent sind - die Schàtzung
wird also deutlich besser.
Spàtestens wenn es zu Änderungen kommt hört es aber auch
damit auf.


Die andere Frage ist, wie ist es wenn ein Datensatz von einem Benutzer für
update gesperrt ist und anderer Benutzer ruft den Datensatz (weil read
uncommitted) auf und fàngt an, in Clint Formular was zu àndern (ohne zu
wissen, dass Datensatz gesperrt ist) und bei bei dem Abschicken der Änderung
was passiert wenn wir nehmen, dass der anderer User fertig mit update ist und
datensatz ist nicht mehr gesperrt.
Wie kann man diese Situation behandeln?



Die wird heute üblicherweise durch optimistische Aktualisierung abgedeckt.
Das heißt bei Änderungen wird der in der Datenbank gespeicherte
Stand mit dem gelesenen verglichen.
Haben sich die Daten zwischenzeitlich geàndert, wird die Änderung
abgewiesen oder - wenn der Programmierer fleißig ist - ein Abgleich
mit dem nun aktuellen Stand vorgenommen/angeboten.

Das Vorgehen vermeidet zum einen lang andauernde Sperren und
ermöglicht so gleichzeitige Zugriffe (ohne NOLOCK/READ UNCOMMITED Krücken).
Und entspricht auch dem üblichen Szenario. Um das Beispiel nochmal
aufzugreifen: Ein Gehalt wird wesentlich hàufiger gelesen als veràndert
(in dem Fall leider ;-). Und noch seltener finden solche Zugriffe
auf einen Lohneintrag parallel statt.

Und nicht zuletzt ist es heute bei getrennten Zugriffen,
die z. B. via WebService uam. stattfinden, gar nicht möglich
Sperren über einen làngeren Zeitraum aufrecht zu erhalten.

Umfassender beschreibt das u. a. die MSDN:
<URL:http://msdn.microsoft.com/en-us/lib...z.aspx>
bzw. deutsch (mit etwas unüblichen Begriffen)
<URL:http://msdn.microsoft.com/de-de/lib...z.aspx>

dort werden auch die dazu erforderlichen SQL Anweisungen
gezeigt (die ein nebenbei .NET CommandBuilder oder auch
LINQ direkt erzeugen).

Gruß Elmar













gibt es da eine Möglichkeit, dem zweiten Benutzer eine Mitteilung schicken,
nachdem eine Änderung von erstem bentzer durchgeführt wurde?

Ähnliche fragen