2.1 Wacan tanpa setya
"Tingkat isolasi transaksi" nuduhake tingkat proteksi sing diwenehake dening mekanisme internal DBMS (yaiku, ora mbutuhake pemrograman khusus) saka kabeh utawa sawetara jinis inconsistencies data ing ndhuwur sing kedadeyan sajrone eksekusi paralel transaksi. Standar SQL-92 nemtokake skala papat tingkat isolasi:
- Maca ora setya
- Read komitmen
- Waca sing bisa diulang
- Serialisable
Sing pisanan yaiku sing paling ringkih, sing pungkasan yaiku sing paling kuat, saben sing sabanjure kalebu kabeh sing sadurunge.
Tingkat isolasi paling ngisor (pisanan). Yen sawetara transaksi paralel nyoba ngowahi baris tabel sing padha, baris pungkasan bakal nduweni nilai sing ditemtokake dening kabeh set transaksi sing kasil rampung. Ing kasus iki, bisa maca ora mung data logis sing ora konsisten, nanging uga data sing owah-owahan durung direkam.
Cara sing khas kanggo ngleksanakake tingkat isolasi iki yaiku ngunci data sajrone prentah nganyari, sing mesthekake yen printah modifikasi ing baris sing padha mlaku kanthi podo karo bener dieksekusi kanthi urutan lan ora ana owah-owahan sing ilang. Transaksi mung diwaca ora tau diblokir ing tingkat isolasi iki.
2.2 Wacan setya
Umume DBMS industri, utamane Microsoft SQL Server, PostgreSQL lan Oracle, nggunakake level iki kanthi standar. Ing tingkat iki, pangayoman marang konsep, maca "kotor" diwenehake, nanging sajrone operasi siji transaksi, liyane bisa kasil rampung lan owah-owahan sing digawe dening iku tetep. Akibaté, transaksi pisanan bakal bisa digunakake karo set data sing beda.
Implementasine maca lengkap bisa adhedhasar salah siji saka rong pendekatan: pamblokiran utawa versi.
Watesan data sing bisa diwaca lan bisa diowahi.
Iku kasusun ing kasunyatan sing transaksi nulis pamblokiran data mutable kanggo maca transaksi operasi ing tingkat setya diwaca utawa luwih nganti rampung, saéngga nyegah maca "reged", lan data dikunci dening transaksi maca dirilis sanalika sawise operasi rampung. SELECT(Mangkono, kahanan "non-repeatable diwaca" bisa dumadi ing tingkat isolasi tartamtu).
Nyimpen pirang-pirang versi baris sing diganti kanthi paralel.
Saben baris diganti, DBMS nggawe versi anyar saka baris iki, karo transaksi sing ngganti data terus bisa, nalika transaksi "maca" liyane ngasilake versi setya pungkasan. Kauntungan saka pendekatan iki yaiku luwih cepet amarga nyegah pamblokiran. Nanging, mbutuhake, dibandhingake karo sing pisanan, konsumsi RAM sing luwih gedhe, sing digunakake kanggo nyimpen versi baris.
Kajaba iku, nalika sawetara transaksi ngganti data ing podo karo, bisa nggawe kahanan ing ngendi sawetara transaksi bebarengan nggawe owah-owahan inconsistent kanggo data sing padha (amarga ora ana kunci, ora ana sing bakal nyegah kedadeyan kasebut). Banjur transaksi sing ditindakake pisanan bakal nyimpen owah-owahan ing basis data utama, lan transaksi paralel sing isih ora bisa ditindakake (amarga iki bakal nyebabake mundhut nganyari transaksi pisanan). Siji-sijine sing bisa ditindakake DBMS ing kahanan kaya ngono yaiku nggulung maneh transaksi liyane lan ngetokake pesen kesalahan "Rekaman wis diganti".
Cara implementasine tartamtu dipilih dening pangembang DBMS, lan ing sawetara kasus bisa disesuaikan. Dadi, kanthi standar, MS SQL nggunakake kunci, nanging (ing versi 2005 lan luwih dhuwur) nalika nyetel READ_COMMITTED_SNAPSHOTparameter database, ngalih menyang strategi versi, Oracle wiwitane mung dianggo miturut skema versi. Ing Informix, sampeyan bisa nyegah konflik antarane transaksi maca lan nulis kanthi nyetel pilihan konfigurasi USELASTCOMMITTED(minangka versi 11.1) sing nyebabake transaksi sing diwaca nampa data setya paling anyar.
2.3 Wacan sing bisa diulang
Tingkat nalika transaksi maca "ora weruh" owah-owahan menyang data sing wis diwaca sadurunge. Ing wektu sing padha, ora ana transaksi liyane sing bisa ngganti data sing diwaca dening transaksi saiki nganti rampung.
Kunci ing mode bareng ditrapake kanggo kabeh data sing diwaca dening instruksi apa wae ing transaksi lan ditahan nganti transaksi rampung. Iki nyegah transaksi liyane saka ngowahi baris sing diwaca dening transaksi sing ditundha. Nanging, transaksi liyane bisa nglebokake baris anyar sing cocog karo kondisi panelusuran kanggo instruksi sing ana ing transaksi saiki. Nalika pratelan kasebut diwiwiti maneh dening transaksi saiki, baris anyar bakal dijupuk, nyebabake maca hantu.
Amarga kunci sing dienggo bareng ditahan nganti pungkasan transaksi, tinimbang diluncurake ing pungkasan saben statement, tingkat konkurensi luwih murah tinimbang tingkat isolasi READ COMMITTED. Mulane, umume ora dianjurake kanggo nggunakake iki lan tingkat transaksi sing luwih dhuwur tanpa perlu.
2.4 Serialisable
Tingkat isolasi paling dhuwur; transaksi rampung diisolasi saka saben liyane, saben dieksekusi kaya-kaya ora ana transaksi paralel. Mung ing tingkat iki transaksi bebarengan ora kena pengaruh "phantom read".
2.5 Dhukungan kanggo isolasi transaksi ing DBMS nyata
DBMS Transaksional ora tansah ndhukung kabeh patang tingkat, lan bisa uga ngenalake level tambahan. Ana uga macem-macem nuansa ing nyediakake insulasi.
Dadi, ing asas, Oracle ora ndhukung tingkat nul, amarga implementasine saka transaksi ora kalebu "maca reged", lan resmi ora ngidini nyetel tingkat maca Repeatable, iku mung ndhukung ( minangka standar) Read committedlan Serializable. Ing wektu sing padha, ing tingkat printah individu, iku bener njamin readability repeatability (yen printah SELECTing transaksi pisanan milih pesawat saka larik saka database, lan ing wektu iki transaksi kapindho podo ngganti sawetara saka baris iki, banjur set asil sing ditampa dening transaksi pisanan bakal ngemot baris sing ora owah, kaya-kaya ora ana transaksi kapindho). Oracle uga ndhukung supaya disebut- READ-ONLYtransaksi, sing cocog karo Serializable, nanging ora bisa ngganti data dhewe.
Lan Microsoft SQL Server ndhukung kabeh papat tingkat isolasi transaksi standar, lan tambahan, tingkat SNAPSHOT, ing ngendi transaksi ndeleng negara data sing dileksanakake sadurunge diluncurake, uga owah-owahan sing digawe dhewe, yaiku, tumindak minangka yen ditampa ing wiwitan, gambar asli seko saka data DB lan dianggo karo. Bentenipun saka Serialized iku ora ana kunci digunakake, nanging minangka asil, nindakake owah-owahan bisa uga ora bisa yen transaksi bebarengan wis diganti data padha sadurunge; ing kasus iki, transaksi kapindho, nalika nyoba kanggo nglakokaké, COMMITbakal mundhakaken pesen kesalahan lan dibatalake.