SQLite verfügt über eine Readers-Writer-Sperre auf Datenbankebene. Mehrere Verbindungen (möglicherweise im Besitz verschiedener Prozesse) können gleichzeitig Daten aus derselben Datenbank lesen, aber nur eine kann in die Datenbank schreiben.
SQLite unterstützt eine unbegrenzte Anzahl gleichzeitiger Leser, erlaubt jedoch zu jedem Zeitpunkt nur einen Schreiber. In vielen Situationen ist dies kein Problem. Warteschlange für Autoren. Jede Anwendung erledigt ihre Datenbankarbeit schnell und geht weiter, und keine Sperre dauert länger als ein paar Dutzend Millisekunden. Es gibt jedoch einige Anwendungen, die mehr Parallelität erfordern, und diese Anwendungen müssen möglicherweise nach einer anderen Lösung suchen. - Geeignete Verwendungen für SQLite @ SQLite.org
Die Readers-Writer-Sperre ermöglicht eine unabhängige Transaktionsverarbeitung und wird mithilfe exklusiver und gemeinsam genutzter Sperren auf Datenbankebene implementiert.
Eine exklusive Sperre muss eingeholt werden, bevor eine Verbindung eine Schreiboperation für eine Datenbank ausführt. Nachdem die exklusive Sperre erhalten wurde, werden sowohl Lese- als auch Schreibvorgänge von anderen Verbindungen blockiert, bis die Sperre wieder aufgehoben wird.
Implementierungsdetails für den Fall gleichzeitiger Schreibvorgänge
SQLite verfügt über eine Sperrtabelle, mit deren Hilfe die Datenbank während eines Schreibvorgangs so spät wie möglich gesperrt werden kann, um maximale Parallelität zu gewährleisten.
Der Anfangszustand ist UNLOCKED, und in diesem Zustand hat die Verbindung noch nicht auf die Datenbank zugegriffen. Wenn ein Prozess mit einer Datenbank verbunden ist und sogar eine Transaktion mit BEGIN gestartet wurde, befindet sich die Verbindung immer noch im Status UNLOCKED.
Nach dem Status UNLOCKED ist der nächste Status der Status SHARED. Um Daten aus der Datenbank lesen (nicht schreiben) zu können, muss die Verbindung zuerst in den Status SHARED versetzt werden, indem eine SHARED-Sperre aktiviert wird. Mehrere Verbindungen können gleichzeitig gemeinsam genutzte Sperren erhalten und verwalten, sodass mehrere Verbindungen gleichzeitig Daten aus derselben Datenbank lesen können. Solange jedoch nur eine SHARED-Sperre nicht freigegeben ist, kann keine Verbindung einen Schreibvorgang in die Datenbank erfolgreich abschließen.
Wenn eine Verbindung in die Datenbank schreiben möchte, muss sie zuerst eine RESERVIERTE Sperre erhalten.
Es kann immer nur eine einzige RESERVIERTE Sperre gleichzeitig aktiv sein, obwohl mehrere gemeinsam genutzte Sperren mit einer einzelnen RESERVIERTEN Sperre koexistieren können. RESERVIERT unterscheidet sich von PENDING dadurch, dass neue SHARED-Sperren erworben werden können, während eine RESERVIERTE Sperre vorhanden ist. - Dateisperrung und Parallelität in SQLite Version 3 @ SQLite.org
Sobald eine Verbindung eine RESERVIERTE Sperre erhält, kann sie mit der Verarbeitung von Datenbankänderungsvorgängen beginnen. Diese Änderungen können jedoch nur im Puffer vorgenommen werden, anstatt tatsächlich auf die Festplatte geschrieben zu werden. Die am Ausleseinhalt vorgenommenen Änderungen werden im Speicherpuffer gespeichert. Wenn eine Verbindung eine Änderung (oder Transaktion) senden möchte, muss die RESERVIERTE Sperre auf eine EXKLUSIVE Sperre aktualisiert werden. Um das Schloss zu erhalten, müssen Sie das Schloss zuerst auf ein PENDING-Schloss heben.
Eine PENDING-Sperre bedeutet, dass der Prozess, der die Sperre hält, so schnell wie möglich in die Datenbank schreiben möchte und nur darauf wartet, dass alle aktuellen SHARED-Sperren gelöscht werden, damit er eine EXKLUSIVE Sperre erhält. Es sind keine neuen SHARED-Sperren für die Datenbank zulässig, wenn eine PENDING-Sperre aktiv ist, obwohl vorhandene SHARED-Sperren fortgesetzt werden dürfen.
Eine EXKLUSIVE Sperre ist erforderlich, um in die Datenbankdatei zu schreiben. Es ist nur eine EXKLUSIVE Sperre für die Datei zulässig, und es dürfen keine anderen Sperren jeglicher Art mit einer EXKLUSIVEN Sperre koexistieren. Um die Parallelität zu maximieren, minimiert SQLite die Zeit, die EXKLUSIVE Sperren gehalten werden. - Dateisperrung und Parallelität in SQLite Version 3 @ SQLite.org
Sie können also sagen, dass SQLite den gleichzeitigen Zugriff durch mehrere Prozesse, die in dieselbe Datenbank schreiben, sicher verarbeitet, nur weil es dies nicht unterstützt! Sie erhalten SQLITE_BUSYoder SQLITE_LOCKEDfür den zweiten Schreiber, wenn er die Wiederholungsbeschränkung erreicht.