AW: Lock Table

[Oliver Six]

Lars Wolff <lars_(at)_zoom-media.de> wrote on 14.12.2001 11:39:11:

>
>> >Uff, bin selbst noch nebie im Thema... wie genau ist das zu verstehen?
>> >Wenn gleichzeitig mehrer Inserts an MySQL kommen, dann würde MySQL die
>> >auch gleichzieig schreiben? Nicht nacheinander abarbeiten?
>
>> >Und was passiert wenn ein Insert auf eine gelockte MySQL Table gemacht
>> >wird? Wartet dann Mysql bis sie wieder geunlocked ist?
>
>> die Inserts serialisiert der MySQL fuer Dich. Deshalb musst Du bei 
>> mehreren Inserts keine Angst haben, dass die Datensaetze durcheinander 
>> gewuerfelt werden. Sollte parallel zu einem Insert ein Select beim 
>> Server eintrudeln, bekommt dieser Select den neu eingefuegten Datensatz 
>> auch nicht zu sehen, bis er komplett ist.
>Das ist ja schon mal schön...
>
>
>> Das einzige Problem, wo Du ein explizites Locking selber machen musst (ob
>> nun ueber 'lock table' oder eine selbst organisierte Sperrtabelle), 
>> stellt die Bearbeitung eines Datensatzes (per Select und spaeterem 
>> Update) auf mehr als einer Client-Maschine dar.
>Sprich, mehrer leute machen einen SELECT und UPDATEN mit
>unterschiedlichen Daten?
>
>Lars
>

Hi Lars,

nur damit wir vom selben reden, ein einfaches Beispiel. Nehmen wir an, wir 
haetten folgende Tabelle: 

CREATE TABLE bla (
  id integer not null auto_increment,
  txt varchar(255),
  index(id)
)

Oeffnen jetzt Client1 und Client2 jeweils genau einen Datensatz mit "select 
* from bla where id=5", so koennen beide diesen Datensatz auf ihrer lokalen 
Maschine veraendern. Nach einer Weile schreibt jetzt Client1 seinen 
Datensatz mit "update bla set txt='neu' where id=5" wieder in die Tabelle. 
Irgendwann schreibt Client2 seinen Datensatz auch wieder   mit "update bla 
set txt='irgendwas' where id=5" in die Tabelle. Damit sind die Aenderungen, 
die Client1 vorgenommen hat, verloren, obwohl er der erste war, der den 
Datensatz angesprochen hat. In genau diesem Fall (und nur diesem!) musst Du 
selber ein Locking der Datensaetze vorsehen, da der Server nicht weiss, wer 
recht behalten soll. Sinnvollerweise sollte Client2 bereits beim Lesen des 
Datensatzes mitgeteilt bekommen, dass er den Datensatz eben nur lesen darf. 

Der Fall, dass beide Clients im selben Moment versuchen, einen Update zu 
fahren, wird - wie bei Insert und allen anderen Datenaenderungen - vom 
MySQL serialisiert. Recht behaelt dann also der, der die Mikrosekunde 
spaeter kam bzw. dessen Zeitscheibe spaeter dran ist. Die Aenderungen am 
Datensatz sehen gleichzeitig laufende Selects auch erst, wenn der Datensatz 
vollstaendig in der Tabelle steht. 

Eine Moeglichkeit, solche Lockings vorzunehmen, koennten evtl. 
Transaktionen sein; sprich man packt den Select und den Update in genau 
eine Transaktion. Das habe ich aber noch nicht ausprobiert und wuerde meine 
Hand auch nicht dafuer ins Feuer legen, dass es funktioniert. Ich fuer 
meinen Teil verwende eine getrennte Tabelle, in der alle gesperrten 
Datensaetze hinterlegt sind. Wenn jetzt Client2 seinen Datensatz liest, 
schaut er gleich noch in die Sperrtabelle, ob, wann und von wem der 
Datensatz gesperrt wurde. Damit kann der User auf Client2 sehen, wer ihn 
gerade am Aendern hindert und - wenn der Datensatz schon eine Ewigkeit 
gesperrt ist - die Sperre entfernen, da Client1 anscheinend abgeraucht ist. 

Ciao Oliver
--
Good programming is 40% experience, 30% skill, 20% RTFM, 10% caffeine, and 
5% attention to detail. 

Oliver Six, CEO
CAHOS GmbH, Cimbernstr. 51, Germany 81377 Muenchen
Phone +49 89 71 01 93 40,  Fax +49 89 71 01 93 41

---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql