11 messages in com.mysql.lists.mysql-deRe: Row Locking| From | Sent On | Attachments |
|---|---|---|
| cps-network (Martin Fernau) | 13 Apr 2006 06:05 | |
| Barry | 13 Apr 2006 06:19 | |
| cps-network (Martin Fernau) | 13 Apr 2006 07:42 | |
| cps-network (Martin Fernau) | 13 Apr 2006 08:03 | |
| Barry | 13 Apr 2006 08:14 | |
| Ingo Strüwing | 13 Apr 2006 08:16 | |
| Barry | 13 Apr 2006 08:17 | |
| cps-network (Martin Fernau) | 13 Apr 2006 08:21 | |
| cps-network (Martin Fernau) | 13 Apr 2006 08:31 | |
| Daniel Penning | 13 Apr 2006 08:52 | |
| cps-network (Martin Fernau) | 13 Apr 2006 09:32 |
| Subject: | Re: Row Locking |
|---|---|
| From: | cps-network (Martin Fernau) (m.fe...@cps-net.de) |
| Date: | 04/13/2006 07:42:16 AM |
| List: | com.mysql.lists.mysql-de |
Am Donnerstag, 13. April 2006 15:20 schrieb Bernhard Janetzki:
Ja, das geht allerdings nur mit InnoDB. http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html
Wie ich schon in mein Ausgangspost schrieb, funktioniert dieses Vorgehen nicht in einer brauchbaren Art und Weise:
Zitat:
"SELECT... FOR UPDATE" geht jedenfalls nicht - oder ich weiss nicht wie. Jedenfalls wurde ein zweites identisches "SELECT ... FOR UPDATE" (in einer zweiten connection zur DB) so lange blockiert, bis das Erste durch ein commit beendet wurde. Auch INSERTs und DELETEs sperrten bis zu einem commit.
Nochmal verdeutlichend:
Ich mache folgendes: - in zwei unterschiedlichen Konsolen verbinde ich mich mit dem SQL-Server - in beiden "use <database>" - in beiden "set autocommit=off;" - in der Ersten tippe ich:
mysql> select * from test where id=5 for update; +------+ | id | +------+ | 5 | | 5 | +------+ 2 rows in set (0.01 sec)
- in der Zweiten tippe ich nun dasselbe ein und drücke Enter. Der Cursor bleibt stehen und die Konsole reagiert so lange nicht mehr auf Eingaben, bis ich im ersten Fenster 'commit' sage.
Mache ich dasselbe unter Java (wo ich das später ja benutzen möchte) in zwei unterschiedlichen Applikationen, schläft die zweite so lange, bis die erste diese Sperre wieder mit commit freigegeben hat. Ergo: absolut unbrauchbar! Das wäre ja vergleichbar, als würde der Benutzer auf den Bearbeiten-Button klicken und die komplette Oberfläche friert so lange ein, bis irgend jemand diesen Satz wieder freigibt. Ich denke nicht, dass das den Anwender besonders beeindrucken würde...
Ich gehe sogar noch ein Schritt weiter. Dieses "SELECT ... for update" sperrt die komplette Tabelle und nicht nur die betroffenen Datensätze wie es eigentlich in der Beschreibung steht. Sage ich ein mal "SELECT * from test where id=5 FOR UPDATE" und in einer anderen Konsole "SELECT * from test where id=3 FOR UPDATE", sperrt die zweite Konsole bis die erste "commit" absetzt und das obwohl die Ergebnissätze nun absolut _nichts_ miteinander gemein haben. Ergo: Um einen einzigen Datensatz zu verändern, wird die komplette Tabelle gesperrt. Das kanns nicht sein...
"SELECT ... FOR UPDATE" und "SELECT ... LOCK IN SHARE MODE" taugen maximal etwas, wenn sie in einer Transaktion in einem Rutsch abgehandelt werden. Ich spreche allerdings von zwei zeitlich getrennten Vorgängen. - Selektieren der Daten und dabei Sperren des Satzes - Anzeige der Daten in einer grafischen Umgebung - Veränderung der Daten durch den Benutzer - speichern der Daten und freigeben der Sperre
Gruß, Martin