Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Christoph Ingenhaag <ChristophIngenhaag@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 26 Nov 2008 04:21:01 -0800
"Elmar Boye" wrote:
....
....
Und deswegen spricht man von einer atomaren Einheit ("A" in "ACID"),
auch wenn es sich in der Ausführung faktisch um mehrere Schritte handelt.
Wenn man je nach Anwendungsfall betrachten muss, was ein Anderer liest, der
auf diesen Wert zugreift dann sind wir beim "I" in "ACID". Wenn man
beispielsweise in der Datenbank read_committed_snapshot angeschaltet hat,
dann liest man in der Isolationsstufe read uncommitted den "aktuellen" Wert
und in der Isolationsstufe read commited den "vorherigen" Wert der laufenden
Update Transaktion. Ein "U"pdate Lock gibts nur bei Anforderung, sonst S und
X.
Wenn der DBA aufgrund von Concurreny Problemen auf read_committed_snapshot
umschaltet, kann es vielleicht die eine oder andere Überraschung geben... ;-)
VG
Christoph
.
- Follow-Ups:
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Elmar Boye
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Henry Habermacher
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- References:
- Locks: Sicheres hochzählen in multiuserumgebung
- From: mike
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Henry Habermacher
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Elmar Boye
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: mike
- Re: Locks: Sicheres hochzählen in multiuserumgebung
- From: Elmar Boye
- Locks: Sicheres hochzählen in multiuserumgebung
- Prev by Date: Re: Abfrageoptimierung
- Next by Date: Re: Saldo ermitteln
- Previous by thread: Re: Locks: Sicheres hochzählen in multiuserumgebung
- Next by thread: Re: Locks: Sicheres hochzählen in multiuserumgebung
- Index(es):