SQLite Transaction: BEGIN, COMMIT, ROLLBACK Kullanımı

Transaction Dediğimiz Şey: Ya Hep Ya Hiç

Bir transaction, birden fazla SQL ifadesini tek bir paket gibi ele almanı sağlar; ya hepsi başarılı olur ya da hiçbiri uygulanmaz. Yarı yolda bir şey ters giderse ROLLBACK ile geri alırsınız ve veritabanı tıpkı işlem başlamadan önceki haline döner.

Bunun en bilindik örneği para transferidir:

CREATE TABLE accounts (
    id    INTEGER PRIMARY KEY,
    owner TEXT,
    cents INTEGER NOT NULL CHECK (cents >= 0)
);

INSERT INTO accounts (owner, cents) VALUES ('Ada', 10000), ('Boris', 500);

BEGIN;
UPDATE accounts SET cents = cents - 2000 WHERE owner = 'Ada';
UPDATE accounts SET cents = cents + 2000 WHERE owner = 'Boris';
COMMIT;

SELECT owner, cents FROM accounts;

İki UPDATE birbirine bağlı işlemler. Eğer veritabanı arada çökerse Ada'nın 2000 kuruşu uçar, Boris ise hiçbir şey kazanmamış olur. Bu ikiliyi BEGIN ... COMMIT arasına almak işlemi atomik hale getirir — ya ikisi birden olur ya da hiçbiri.

Autocommit modu: Zaten kullandığınız varsayılan davranış

Şu ana kadar çalıştırdığınız her SQL ifadesi aslında bir transaction'dı. SQLite varsayılan olarak autocommit modunda çalışır: her ifadenin başına ve sonuna otomatik olarak BEGIN ve COMMIT eklenir.

CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);

INSERT INTO notes (body) VALUES ('birinci');
INSERT INTO notes (body) VALUES ('ikinci');
INSERT INTO notes (body) VALUES ('üçüncü');

SELECT * FROM notes;

Üç ayrı INSERT, üç ayrı transaction, diske üç ayrı fsync çağrısı. Tek seferlik yazmalar için sorun değil ama toplu yüklemelerde resmen yavaşlatıyor — üstelik bir grup ifadeyi tek parça halinde geri almak da imkânsız hale geliyor. İşte tam burada BEGIN devreye giriyor: bir sonraki COMMIT ya da ROLLBACK'e kadar autocommit modunu kapatıyor.

ROLLBACK: Hiç Olmamış Gibi Davranmak

ROLLBACK, ilgili BEGIN'den sonra yapılan her şeyi siler atar. Veritabanı, transaction öncesi haline geri döner.

CREATE TABLE inventory (item TEXT PRIMARY KEY, qty INTEGER);
INSERT INTO inventory VALUES ('apple', 10), ('pear', 5);

BEGIN;
UPDATE inventory SET qty = 0 WHERE item = 'apple';
DELETE FROM inventory WHERE item = 'pear';
ROLLBACK;

SELECT * FROM inventory;

UPDATE ve DELETE ifadelerinin ikisi de buharlaşır; tablo BEGIN öncesindeki haline geri döner. İşte tam da bu, çok adımlı bir işlemin ortasında hata patladığında uygulama kodunun temiz bir şekilde geri çekilmesini sağlayan emniyet ağıdır.

Bu arada, transaction içindeki bir constraint ihlali tüm işlemi otomatik olarak geri almaz. Yalnızca hatalı ifadeyi geri alır ve transaction'ı açık bırakır; kararı sana bırakır. "Ya hep ya hiç" mantığı istiyorsanız, hatayı gören uygulamanın kendisi ROLLBACK çalıştırmak zorunda.

Toplu Insert İşlemlerini Hızlandırma

Autocommit modunda her ifade kendi fsync'ini yaptığı için, bir grup işlemi tek bir transaction içine almak çoğu zaman 100 kat hız kazandırır:

CREATE TABLE events (id INTEGER PRIMARY KEY, payload TEXT);

BEGIN;
INSERT INTO events (payload) VALUES ('a');
INSERT INTO events (payload) VALUES ('b');
INSERT INTO events (payload) VALUES ('c');
INSERT INTO events (payload) VALUES ('d');
INSERT INTO events (payload) VALUES ('e');
COMMIT;

SELECT count(*) FROM events;

COMMIT anında diske tek bir senkronizasyon yapılır, her satır için ayrı ayrı değil. Binlerce satır içe aktarırken işlemin neden kaplumbağa hızında ilerlediğini merak ediyorsanız, cevap genelde tam olarak budur.

DEFERRED, IMMEDIATE, EXCLUSIVE farkı

BEGIN, SQLite'ın kilitleri ne zaman alacağını belirleyen bir mod parametresi kabul eder:

• BEGIN DEFERRED (varsayılan) — sen okuma ya da yazma yapana kadar hiçbir kilit alınmaz. Yazma kilidi tembel davranır; ilk yazma ifadesinde devreye girer.
• BEGIN IMMEDIATE — yazma kilidini hemen kapar. Diğer bağlantılar okumaya devam edebilir ama başka hiçbir bağlantı yazma işlemi başlatamaz.
• BEGIN EXCLUSIVE — IMMEDIATE gibidir, ek olarak başka bağlantılar okuma da yapamaz. WAL modunda bu, IMMEDIATE ile aynı şekilde çalışır; fark yalnızca eski rollback journal modunda anlam kazanır.

BEGIN DEFERRED;     -- düz BEGIN ile aynı
BEGIN IMMEDIATE;    -- yazma kilidini şimdi al
BEGIN EXCLUSIVE;    -- her şeyi rezerve et (rollback-journal modu)

Bu seçim, eşzamanlılık (concurrency) açısından kritik. Düz bir BEGIN kullandığınızda iki bağlantı aynı anda transaction başlatabilir, ikisi de keyifle okuma yapabilir, sonra yazma sırası geldiğinde birbirine girerler — write lock'u ikinci isteyen bağlantı SQLITE_BUSY hatası alır ve dahası, bu noktaya kadar yaptığı okumaları çöpe atmak zorunda kalır.

BEGIN IMMEDIATE tam da bu sorunu çözer: yazacağınızı biliyorsanız, write lock'u en başta isteyin. İkinci bağlantı hiç boşa iş yapmadan, en baştan ya bloklanır ya da hızlıca hata döner.

Pratik kural: transaction'ınız yazma yapacaksa BEGIN IMMEDIATE kullanın.

Transaction İçindeki Okumalar Snapshot Görür

Bir transaction açıkken yaptığınız okumalar, veritabanının tutarlı bir anlık görüntüsünü (snapshot) görür: WAL modunda transaction başladığı andaki hali, rollback-journal modunda ise ilk okumayı yaptığınız andaki hali. Başka bağlantılar bu sırada commit yapsa bile, bu değişiklikler sizin sorgularınızda bir anda belirivermez.

CREATE TABLE counter (n INTEGER);
INSERT INTO counter VALUES (1);

BEGIN;
SELECT n FROM counter;   -- 1
UPDATE counter SET n = 99;
SELECT n FROM counter;   -- 99, kendi yazdığın değer görünür
COMMIT;

SELECT n FROM counter;

Kendi commit'lenmemiş yazdıklarınızı siz görürsünüz; başka bağlantılar göremez. COMMIT yaptığınız anda yeni değer artık herkese görünür hale gelir. İnsanların "SQLite serializable'dır" derken kastettiği şey tam olarak budur — çevirebileceğiniz bir READ COMMITTED ayarı yok, çünkü varsayılan zaten en güçlü izolasyon seviyesi.

Uygulama Kodunda Transaction Kullanımı

Gerçek bir uygulamada bu işin kalıbı genelde şöyledir: gövdeyi try/except (ya da try/catch) bloğuna alırsınız ve hata durumunda ROLLBACK çalıştırırsınız:

-- Herhangi bir istemci kütüphanesi için sözde kod
BEGIN IMMEDIATE;
try:
    UPDATE accounts SET cents = cents - 2000 WHERE owner = 'Ada';
    UPDATE accounts SET cents = cents + 2000 WHERE owner = 'Boris';
    COMMIT;
except:
    ROLLBACK;
    raise;

Çoğu istemci kütüphanesi (Python'un sqlite3'ü, better-sqlite3 vb.) bu işi sizin için bir with bloğu ya da transaction() yardımcısıyla sarmalıyor. Kullandığınız kütüphanenin dokümantasyonuna göz atmakta fayda var — varsayılan davranışlar her zaman beklediğiniz gibi olmuyor. Özellikle Python'un sqlite3 modülü tarihsel olarak tuhaf bir autocommit davranışına sahipti; son sürümlerde bunu düzeltmek için düzgün bir autocommit parametresi eklendi.

İnsanların Sıkça Takıldığı Noktalar

• DDL komutları transaction içinde çalışır. CREATE TABLE, ALTER TABLE, hatta DROP TABLE bile geri alınabilir. SQLite bu konuda alışılmadık — birçok veritabanı DDL'i otomatik olarak commit eder.
• VACUUM transaction içinde çalışmaz. Birkaç bakım komutu da öyle. Bunları autocommit modunda çalıştırın.
• Başarısız bir COMMIT gerçek bir hatadır. COMMIT SQLITE_BUSY döndürürse (nadir ama mümkün), transaction commit edilmemiştir. Kodunuzun bu durumu ele alması gerekir — genelde tekrar deneyerek.
• Uzun transaction'lar yazıcıları bloklar. Dakikalarca açık kalan bir transaction, diğer yazıcıları da dakikalarca bloklar. Geç açın, hızlıca commit edin.

Sırada: Savepoint'ler

BEGIN ve COMMIT ya hep ya hiç mantığıyla çalışır. Bazen ise transaction'ın sadece bir kısmını geri almak istersiniz — örneğin riskli bir adımdan vazgeçip geri kalanı tutmak gibi. Savepoint'ler tam da bunun için var ve sıradaki konumuz onlar.