Skip navigation links
15.9.2 Implementierung der Funktion external_lock() »
Section Navigation      [Toggle]

15.9.1. Implementierung der Funktion store_lock()

Die Funktion store_lock() wird vor allen Lese- und Schreibvorgängen aufgerufen.

Bevor die Sperre dem Tabellensperren-Handler hinzugefügt wird, ruft mysqld die Funktion store_lock() mit den erforderlichen Sperren auf. Die Funktion kann das Ausmaß der Sperrung ändern, also beispielsweise eine blockierende Schreibsperre in eine nichtblockierende umwandeln, die Sperre ignorieren (wenn keine MySQL-Tabellensperren benutzt werden sollen) oder Sperren für viele Tabellen hinzufügen (wie es bei Verwendung eines MERGE-Handlers getan wird).

Berkeley DB stuft beispielsweise blockierende Tabellensperren vom Typ TL_WRITE zu nichtblockierenden TL_WRITE_ALLOW_WRITE-Sperren herab (ein Hinweis darauf, dass zwar WRITE-Operationen stattfinden, aber dennoch andere lesende und schreibende Prozesse zugelassen sind).

Auch beim Aufheben von Sperren wird store_lock() aufgerufen. In diesem Fall muss in der Regel nichts weiter veranlasst werden.

Wenn store_lock das Argument TL_IGNORE bekommt, bedeutet das, dass MySQL vom Handler verlangt, dasselbe Ausmaß der Sperrung wie beim letzten Mal zu speichern.

Die möglichen Sperrentypen sind in includes/thr_lock.h definiert und werden hier noch einmal aufgeführt: 

enum thr_lock_type
{
         TL_IGNORE=-1,
         TL_UNLOCK,			             /* SPERREN AUFHEBEN */
 	  TL_READ,			               /* Lesesperre */
 	  TL_READ_WITH_SHARED_LOCKS,  
         TL_READ_HIGH_PRIORITY,      /* Hat Priorität vor TL_WRITE. Nebenläufige Einfügeoperationen zulässig*/
         TL_READ_NO_INSERT, 		     /* READ, nebenläufige Einfügeoperationen unzulässig */
         TL_WRITE_ALLOW_WRITE, 		   /*	Schreibsperre, aber andere Threads dürfen lesen/schreiben. */
         TL_WRITE_ALLOW_READ,        /*	Schreibsperre, aber andere Threads dürfen lesen/schreiben. */
         TL_WRITE_CONCURRENT_INSERT, /* WRITE-Sperre, die von nebenläufigen Einfügeoperationen benutzt wird. */
         TL_WRITE_DELAYED,  		     /* Schreibvorgang, der von INSERT DELAYED verwendet wird.  READ-Sperren zulässig */
         TL_WRITE_LOW_PRIORITY,	     /* WRITE-Sperre mit geringerer Priorität als TL_READ */
         TL_WRITE,          		     /* Normale WRITE-Sperre */
         TL_WRITE_ONLY               /* Jede neue Sperranforderung wird mit einem Fehler abgebrochen*/
};

Der tatsächliche Umgang mit Sperren hängt von der Implementierung Ihrer Sperren ab. Sie können alle, einige oder gar keine der geforderten Sperrentypen implementieren und eigene Methoden verwenden, wo es Ihnen passend erscheint. Im Folgenden sehen Sie eine Minimalimplementierung für eine Speicher-Engine, die keine Sperren herabstufen muss: 

THR_LOCK_DATA **ha_tina::store_lock(THD *thd,
                                     THR_LOCK_DATA **to,
                                     enum thr_lock_type lock_type)
{
   if (lock_type != TL_IGNORE && lock.type == TL_UNLOCK)
     lock.type=lock_type;
   *to++= &lock;
   return to;
}

Eine komplexere Implementierung finden Sie unter ha_berkeley::store_lock() und ha_myisammrg::store_lock().

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.