InnoDB und Lock Tables
am 24.03.2006 20:39:38 von Glenn Kusardi
Hallo,
eine bestehende Anwendung soll auf die Unterstützung von Transaktionen
umgestellt werden. Dabei treten nun viele Dead Locks auf, die wir im
Moment nicht lösen können.
Das Einfachste um die Transaktionen zu serialisieren und somit jegliche
Dead Lock Situationen zu vermeiden, ist ein LOCK TABLES und UNLOCK
TABLES mit Beginn und Ende einer Transaktion.
Leider macht das unter InnoDB Probleme, die Verwendung von LOCK TABLES
im Zusammenhang mit InnoDB und Transaktionen sollte, laut Manual [1],
aber durchaus möglich sein.
Kann mir da jemand auf die Sprünge helfen? Folgender Versuch hat nicht
funktioniert:
SET AUTOCOMMIT =3D 0;
START TRANSACTION;
LOCK TABLES table WRITE;
UPDATE table SET column =3D 1;
COMMIT;
UNLOCK TABLES;
Viele Grüße,
Glenn
[1] http://dev.mysql.com/doc/refman/4.1/en/innodb-locks-set.html
Re: InnoDB und Lock Tables
am 25.03.2006 00:18:02 von Dirk Brosowski
Glenn Kusardi schrieb:
> Hallo,
> ....
auch wenn ich dir voraussichtlich nicht helfen kann, weil das net mein
Spezialgebiet ist, so suche ich doch die Beschreibung der Probleme bzw.
was genau an dem Versuch nicht funktioniert hat.
Wobei ich auch bezweifele, dass man durch explizite globale Locks
Dead-Locks verhindern kann. Irgendwie erschließt sich mir das noch nicht.
Grüße
Dirk
Re: InnoDB und Lock Tables
am 25.03.2006 20:28:59 von Glenn Kusardi
Dirk Brosowski wrote:
> auch wenn ich dir voraussichtlich nicht helfen kann, weil das net mein
> Spezialgebiet ist, so suche ich doch die Beschreibung der Probleme bzw.
> was genau an dem Versuch nicht funktioniert hat.
es wurde kein LOCK TABLES ausgeführt, der andere Prozess konnte also
an gleichen Daten parallel arbeiten. Gerade eben hab ich es aber noch
mal in der MySQL-Konsole ausprobiert, da hat es funktioniert.
Seltsam in der Anwendung hatte das Probleme gemacht, da werde ich wohl
doch noch etwas rumprobieren müssen.
> Wobei ich auch bezweifele, dass man durch explizite globale Locks
> Dead-Locks verhindern kann. Irgendwie erschließt sich mir das noch nich=
t
Durch das Sperren ganzer Tabellen kann es keine Situationen geben in
dem zwei Transaktionen gegenseitig auf einen Lock der jeweils anderen
Transaktion warten. Jede Transaktion wird streng hintereinander
abgearbeitet werden. Dadurch kann es zu solchen Situationen nicht
kommen.
Dead Locks können nur dann entstehen, wenn zwei Transaktionen parallel
auf gleichen Daten arbeiten. Und das wird durch das Sperren von
Tabellen umgangen.
Die Performance leidet natürlich stark unter den Tabellen-Locks.
Viele Grüße,
Glenn
Re: InnoDB und Lock Tables
am 26.03.2006 04:04:54 von Axel Schwenke
"Glenn Kusardi" wrote:
>
>> Wobei ich auch bezweifele, dass man durch explizite globale Locks
>> Dead-Locks verhindern kann. Irgendwie erschließt sich mir das noch nicht
>
> Durch das Sperren ganzer Tabellen kann es keine Situationen geben in
> dem zwei Transaktionen gegenseitig auf einen Lock der jeweils anderen
> Transaktion warten.
Kann es wohl. Transaktionen sind nicht notwendigerweise auf eine
einzelne Tabelle beschränkt. Genau genommen sind sie das fast nie.
> Dead Locks können nur dann entstehen, wenn zwei Transaktionen parallel
> auf gleichen Daten arbeiten. Und das wird durch das Sperren von
> Tabellen umgangen.
Nein. Lies das Handbuch:
http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html
Man *kann* durch explizite TABLE LOCKs Deadlocks vermeiden. Aber nicht
automatisch (nyyr Genafnxgvbara züffra qvr orgrvyvtgra Gnoryyra va qre
tyrvpura Ervurasbytr ybpxra).
> Die Performance leidet natürlich stark unter den Tabellen-Locks.
Ja.
XL
Re: InnoDB und Lock Tables
am 26.03.2006 14:22:29 von Glenn Kusardi
Axel Schwenke wrote:
> > Durch das Sperren ganzer Tabellen kann es keine Situationen geben in
> > dem zwei Transaktionen gegenseitig auf einen Lock der jeweils anderen
> > Transaktion warten.
> Kann es wohl. Transaktionen sind nicht notwendigerweise auf eine
> einzelne Tabelle beschränkt. Genau genommen sind sie das fast nie.
Das ist mir klar, ich bezog mich auch auf das Sperren der beteiligten
Tabellen, deswegen die Verwendung des Plurals.
> > Dead Locks können nur dann entstehen, wenn zwei Transaktionen parallel
> > auf gleichen Daten arbeiten. Und das wird durch das Sperren von
> > Tabellen umgangen.
> Nein. Lies das Handbuch:
> http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html
> Man *kann* durch explizite TABLE LOCKs Deadlocks vermeiden. Aber nicht
> automatisch (nyyr Genafnxgvbara züffra qvr orgrvyvtgra Gnoryyra va qre
> tyrvpura Ervurasbytr ybpxra).
"Table-level locks make your transactions queue nicely, and deadlocks
are avoided.", alles unter der Voraussetzung das alle beteiligten
Tabellen gesperrt sind, wie beschrieben.
Glenn
Re: InnoDB und Lock Tables
am 26.03.2006 16:38:50 von Axel Schwenke
"Glenn Kusardi" wrote:
> Axel Schwenke wrote:
>
>> Man *kann* durch explizite TABLE LOCKs Deadlocks vermeiden. Aber nicht
>> automatisch (nyyr Genafnxgvbara züffra qvr orgrvyvtgra Gnoryyra va qre
>> tyrvpura Ervurasbytr ybpxra).
>
> "Table-level locks make your transactions queue nicely, and deadlocks
> are avoided.", alles unter der Voraussetzung das alle beteiligten
> Tabellen gesperrt sind, wie beschrieben.
Aber nur, wenn man die Randbedingungen beachtet. Das Manual
ist hier leider nicht so ausführlich, wie es sein sollte.
Thread A: lockt Tabelle A, zeitgleich
Thread B: lockt Tabelle B
Thread A: will Tabelle B locken
Thread B: will Tabelle A locken
und schon hast du ein schönes Deadlock trotz Table-locks.
XL
Re: InnoDB und Lock Tables
am 26.03.2006 23:58:45 von Glenn Kusardi
Axel Schwenke wrote:
> Thread A: lockt Tabelle A, zeitgleich
> Thread B: lockt Tabelle B
> Thread A: will Tabelle B locken
> Thread B: will Tabelle A locken
> und schon hast du ein schönes Deadlock trotz Table-locks.
Stimmt, ich ging aber immer von:
Thread A: LOCK TABLES A WRITE, B WRITE;
Thread B: LOCK TABLES A WRITE, B WRITE;
aus. Also von dem Sperren der betroffenen Tabellen in einem Statement.
Da kann der Fall nicht auftreten, das meinte ich mit dem Sperren aller
betroffenen Tabellen. Sorry, da haben wir aneinander vorbei geredet.
Grüße,
Glenn