Re: Lock-Probleme

["Matthias Urlichs" <smurf_(at)_noris.net>]

Hi,

Dieter Spieß:
> 1. Ein Client setzt auf eine Tabelle ein Write- oder Read-Lock.
>    Wie kann ein anderer Client _vor_ einem Schreib- oder Lese-      
> Zugriff feststellen, ob und welcher ein Lock vorliegt ?
> 
Gar nicht. Es bringt nichts.

Client A               Client B
Lock?  => NEIN
                       Lock! => ERFOLG
Zugriff => blockiert

> 2. Client A lädt über SQL einen Datensatz zum Editieren
>    Änderungen: Strasse und Telefonnummer
>    Client B lädt über SQL den gleichen Datensatz mit den 
>    alten Inhalten    Änderungen: Umsatz
>    Client A speichert den Datensatz mit _seinen_ neuen Inhalten
>    Client B speichert den Datensatz mit _seinem_ neuen Inhalt
> 
"Den Datensatz" komplett zurückzuschreiben ist Unsinn.

>    Ergebnis: Der Datensatz enthält zwar den neuen Umsatz, aber
>    die alte Strasse und Telefonnummer
>    
Wieso updatest du beim Ändern überhaupt irgendwas, was du nicht geändert
hast?

>    Wie werden solche Standardprobleme mit MySQL gelöst ?

UPDATE Tabelle SET NeuesFeld = NeuerInahtl WHERE Index=12345 AND
                                                 NeuesFeld = AlterInhalt

=> wenn dir jemand reingepfuscht hat, wurde nix geupdatet.
(Die Abfrage liefert die Anzahl der geänderten Datensätze zurück.)

Oder:

UPDATE Tabelle SET Umsatz = Umsatz+MehrUmsatz WHERE KundeID = 23456

Das ist in jedem Fall atomar und kann dir nichts kaputtmachen.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf_(at)_noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
More than any other time in history, mankind faces a crossroads.  One
path leads to despair and utter hopelessness.  The other, to total
extinction.  Let us pray we have the wisdom to choose correctly.
                -- Woody Allen

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe