Disconnect/Reconnect (was: phpMyAdmin)
- From: Kristian Köhntopp <kris-usenet2009@xxxxxxxxxxxx>
- Date: Fri, 17 Apr 2009 13:13:41 +0200
On 2009-04-13 15:39:21 +0200, Claus Reibenstein <4spamersonly@xxxxxxxxx> said:
Vergiss das Mantra. Das ist ein Relikt aus den Anfangszeiten von
phpMyAdmin und wird wohl nur von Leuten angeführt, die sich aus Prinzip
nicht mit der technischen Entwicklung des monierten Werkzeugs
auseinandersetzen wollen.
phpMyAdmin unterliegt wie auch viele grafische Werkzeuge für MySQL (darunter auch jene, die von MySQL selbst bereitgestellt werden) einigen besonderen Einschränkungen. Diese sind prinzipbedingt und daher auch nicht leicht zu beheben.
Aber von vorne (und Ihr könnt diesen Artikel gerne in eine FAQ kloppen):
In MySQL ist es so, daß die Connection einen besonderen Kontext oder Scope darstellt. Mindestens die folgenden Dinge sind mit dem Scope der Connection definiert:
- Transaktionen. Ein Disconnect entspricht einen ROLLBACK.
- @-Variablen. SET @bla = 10 oder SELECT @bla := count(*) FROM keks; definieren jeweils eine Connectionvariable mit dem Namen @bla, die beim Disconnect verloren ist.
- SESSION-Parameter. SET SESSION mysiam_sort_buffer_size = 1024*1024*64 oder SET @@session.myisam_sort_buffer_size = 1024*1024*64 sind nach einen Disconnect verloren. Dies gilt auch für die häufig gesetzten Character Sets (SET NAMES ist nur ein Kürzel für drei bestimmte SET SESSION ...).
Wir nennen so etwas Zustand im Scope der Connection oder Connection Scoped State (CSS, mal wieder :) ).
Ein Client, der also unkontrolliert disconnected oder bei dem ein Disconnect nicht korrekt gemeldet wird, ist defekt in dem Sinne, daß die o.a. Funktionalität nicht wie erwartet verfügbar ist.
Das gilt für viele grafische Clients - viele von denen machen nach dem Absenden der Query und dem Lesen des Resultsets einen Disconnect und verbinden sich für die folgende Query neu, darunter auch der MySQL Query Browser.
Das gilt auch für einige veraltete Versionen von Connectoren. Eine Zeit lang dachte das MySQL Connector/J-Team zum Beispiel, es sei eine gute Idee, Auto-Reconnect bei Verlust der Connection aus welchem Grund auch immer zu machen statt eine Java Exception dafür zu schmeissen. Wenn einem das mitten in einer Transaktion passiert und der Connector dann einfach wieder verbindet statt die Exception zu werfen kann man ein paar echt schwer zu findende Heisenbugs bauen.
Und das gilt prinzipbedingt auch für jeden Webclient wie phpMyAdmin einer ist. Es ist nun mal so, daß etwa Apache einen Haufen Worker Slaves hat und daß ein eingehender http-Request einen zufälligen Worker Slave zugeteilt wird. Es wäre also selbst mit mysql_pconnect() nicht möglich einen phpMyAdmin zu schreiben, der CSS korrekt behandelt.
Kann Dein Client CSS?
Definiere in einer Query eine Sessionvariable: SET @bla = 'Ich bin korrekt';
In einer zweiten Query frage den Wert der Variaben ab: SELECT @bla;
Wenn Dein Client mit 'Ich bin korrekt' antwortet, kann er CSS verwalten. Ansonsten ist er unbrauchbar und gehört auf den Müll - wer will schon einen Datenbankclient, mit dem man nicht mal eine Transaktion korrekt verwalten kann?
Kris
.
- Follow-Ups:
- Re: Disconnect/Reconnect (was: phpMyAdmin)
- From: Kristian Köhntopp
- Re: Disconnect/Reconnect
- From: Claus Reibenstein
- Re: Disconnect/Reconnect (was: phpMyAdmin)
- References:
- datediff
- From: Mathias Fiedler
- Re: datediff
- From: Harald Stowasser
- phpMyAdmin [was: datediff]
- From: Niels Braczek
- Re: phpMyAdmin
- From: Niels Braczek
- Re: phpMyAdmin
- From: Claus Reibenstein
- datediff
- Prev by Date: Re: phpMyAdmin
- Next by Date: Re: datediff
- Previous by thread: Re: phpMyAdmin
- Next by thread: Re: Disconnect/Reconnect
- Index(es):
Relevant Pages
|
