2.1 Magbasa nang hindi nakatuon
Ang "antas ng paghihiwalay ng transaksyon" ay tumutukoy sa antas ng proteksyon na ibinibigay ng mga panloob na mekanismo ng DBMS (iyon ay, hindi nangangailangan ng espesyal na programming) mula sa lahat o ilan sa mga uri sa itaas ng mga hindi pagkakapare-pareho ng data na nangyayari sa panahon ng parallel na pagpapatupad ng mga transaksyon. Ang pamantayang SQL-92 ay tumutukoy sa isang sukat ng apat na antas ng paghihiwalay:
- Basahin nang hindi nakatuon
- Read committed
- Paulit-ulit na pagbabasa
- Serializable
Ang una sa kanila ay ang pinakamahina, ang huli ay ang pinakamalakas, ang bawat kasunod ay kinabibilangan ng lahat ng nauna.
Ang pinakamababang (unang) antas ng paghihiwalay. Kung sinubukan ng ilang magkakatulad na transaksyon na baguhin ang parehong hilera ng talahanayan, ang huling row ay magkakaroon ng halaga na tinutukoy ng buong hanay ng matagumpay na nakumpletong mga transaksyon. Sa kasong ito, posible na basahin hindi lamang ang lohikal na hindi pantay na data, kundi pati na rin ang data na ang mga pagbabago ay hindi pa naitala.
Ang isang karaniwang paraan upang ipatupad ang antas ng paghihiwalay na ito ay ang pag-lock ng data para sa tagal ng utos ng pag-update, na nagsisiguro na ang mga utos ng pagbabago sa parehong mga hilera na tumatakbo nang magkatulad ay aktwal na isinasagawa nang sunud-sunod at wala sa mga pagbabago ang nawala. Ang mga read-only na transaksyon ay hindi kailanman na-block sa ilalim ng antas ng paghihiwalay na ito.
2.2 Read committed
Karamihan sa mga pang-industriya na DBMS, sa partikular na Microsoft SQL Server, PostgreSQL at Oracle, ay gumagamit ng antas na ito bilang default. Sa antas na ito, ang proteksyon laban sa draft, "marumi" na pagbabasa ay ibinigay, gayunpaman, sa panahon ng pagpapatakbo ng isang transaksyon, ang isa pa ay maaaring matagumpay na makumpleto at ang mga pagbabagong ginawa nito ay naayos. Bilang resulta, gagana ang unang transaksyon sa ibang set ng data.
Ang pagpapatupad ng isang kumpletong pagbabasa ay maaaring batay sa isa sa dalawang diskarte: pagharang o bersyon.
Hinaharang ang nababasa at nababagong data.
Binubuo ito sa katotohanan na hinaharangan ng transaksyon sa pagsulat ang nababagong data para sa pagbabasa ng mga transaksyon na tumatakbo sa antas ng read committed o mas mataas hanggang sa ito ay makumpleto, kaya pinipigilan ang "marumi" na pagbabasa, at ang data na naka-lock ng transaksyon sa pagbabasa ay inilabas kaagad pagkatapos makumpleto ang operasyon. SELECT( kaya, maaaring mangyari ang isang "hindi nauulit na pagbabasa" na sitwasyon sa isang partikular na antas ng paghihiwalay).
Nagse-save ng maraming bersyon ng mga row na nagbabago nang magkatulad.
Sa tuwing babaguhin ang isang row, gagawa ang DBMS ng bagong bersyon ng row na ito, kung saan patuloy na gagana ang transaksyong nagpabago sa data, habang ibinabalik ng anumang transaksyong "pagbabasa" ang huling ginawang bersyon. Ang bentahe ng diskarteng ito ay mas mabilis ito dahil pinipigilan nito ang pagharang. Gayunpaman, nangangailangan ito, sa paghahambing sa una, ng isang makabuluhang mas malaking pagkonsumo ng RAM, na ginugol sa pag-iimbak ng mga bersyon ng hilera.
Bilang karagdagan, kapag maraming mga transaksyon ang nagbabago ng data nang magkatulad, maaari itong lumikha ng isang sitwasyon kung saan ang ilang kasabay na mga transaksyon ay nagsasagawa ng hindi pantay-pantay na mga pagbabago sa parehong data (dahil walang mga lock, walang makakapigil dito na mangyari). Pagkatapos ang transaksyon na unang gumawa ay magse-save ng mga pagbabago nito sa pangunahing database, at ang natitirang mga parallel na transaksyon ay magiging imposibleng gawin (dahil hahantong ito sa pagkawala ng pag-update ng unang transaksyon). Ang tanging bagay na magagawa ng DBMS sa ganitong sitwasyon ay ibalik ang natitirang mga transaksyon at mag-isyu ng mensahe ng error na "Nabago na ang talaan".
Ang isang partikular na paraan ng pagpapatupad ay pinili ng mga developer ng DBMS, at sa ilang mga kaso maaari itong i-customize. Kaya, bilang default, ang MS SQL ay gumagamit ng mga kandado, ngunit (sa bersyon 2005 at mas mataas) kapag nagtatakda ng READ_COMMITTED_SNAPSHOTparameter ng database, lumipat ito sa diskarte sa pag-bersyon, ang Oracle sa una ay gumagana lamang ayon sa bersyon na pamamaraan. Sa Informix, mapipigilan mo ang mga salungatan sa pagitan ng mga transaksyong read at write sa pamamagitan ng pagtatakda ng opsyon sa pagsasaayos USELASTCOMMITTED(mula sa bersyon 11.1) na nagiging sanhi upang matanggap ng read transaction ang pinakabagong naka-commit na data.
2.3 Paulit-ulit na pagbasa
Ang antas kung saan ang isang transaksyon sa pagbabasa ay "hindi nakikita" ay nagbabago sa data na dati nitong nabasa. Kasabay nito, walang ibang transaksyon ang makakapagpabago sa data na nabasa ng kasalukuyang transaksyon hanggang sa matapos ito.
Ang mga lock sa shared mode ay inilalapat sa lahat ng data na binabasa ng anumang tagubilin sa isang transaksyon at gaganapin hanggang sa makumpleto ang transaksyon. Pinipigilan nito ang iba pang mga transaksyon na baguhin ang mga row na nabasa ng nakabinbing transaksyon. Gayunpaman, ang ibang mga transaksyon ay maaaring magpasok ng mga bagong linya na tumutugma sa mga kundisyon sa paghahanap para sa mga tagubiling nakapaloob sa kasalukuyang transaksyon. Kapag na-restart ang statement ng kasalukuyang transaksyon, kukuha ng mga bagong row, na magreresulta sa isang phantom read.
Dahil ang mga shared lock ay gaganapin hanggang sa katapusan ng transaksyon, sa halip na ilabas sa dulo ng bawat statement, ang antas ng concurrency ay mas mababa kaysa sa antas ng paghihiwalay READ COMMITTED. Samakatuwid, sa pangkalahatan ay hindi inirerekomenda na gamitin ito at mas mataas na antas ng transaksyon nang hindi kinakailangan.
2.4 Nai-serialize
Ang pinakamataas na antas ng paghihiwalay; ang mga transaksyon ay ganap na nakahiwalay sa isa't isa, ang bawat isa ay isinasagawa na parang walang mga parallel na transaksyon. Sa antas lamang na ito na ang mga kasabay na transaksyon ay hindi napapailalim sa "phantom read" na epekto.
2.5 Suporta para sa paghihiwalay ng transaksyon sa totoong DBMS
Hindi palaging sinusuportahan ng Transaksyonal na DBMS ang lahat ng apat na antas, at maaari ring magpakilala ng mga karagdagang. Mayroon ding iba't ibang mga nuances sa pagbibigay ng pagkakabukod.
Kaya, sa prinsipyo, hindi sinusuportahan ng Oracle ang zero level, dahil ang pagpapatupad nito ng mga transaksyon ay hindi kasama ang "marumi na mga pagbabasa", at pormal na hindi pinapayagan ang pagtatakda ng Repeatable read level, iyon ay, sinusuportahan lamang nito ( bilang default) Read committedat Serializable. Kasabay nito, sa antas ng mga indibidwal na utos, talagang ginagarantiyahan nito ang read repeatability (kung ang isang command SELECTsa unang transaksyon ay pumili ng isang hanay ng mga hilera mula sa database, at sa oras na ito ang isang magkatulad na pangalawang transaksyon ay nagbabago ng ilan sa mga row na ito, pagkatapos ay ang Ang set ng resulta na natanggap ng unang transaksyon ay maglalaman ng mga hindi nabagong row, na parang walang pangalawang transaksyon). Sinusuportahan din ng Oracle ang tinatawag na READ-ONLYmga transaksyon, na tumutugma sa Serializable, ngunit hindi maaaring baguhin ang data mismo.
At sinusuportahan ng Microsoft SQL Server ang lahat ng apat na karaniwang antas ng paghihiwalay ng transaksyon, at bilang karagdagan, ang antas ng SNAPSHOT, kung saan nakikita ng transaksyon ang estado ng data na ginawa bago ito inilunsad, pati na rin ang mga pagbabagong ginawa mismo, iyon ay, kumikilos ito bilang kung natanggap ito sa pagsisimula, isang snapshot ng data ng DB at gumagana kasama nito. Ang pagkakaiba sa Serialized ay walang lock na ginagamit, ngunit bilang resulta, ang paggawa ng mga pagbabago ay maaaring hindi posible kung ang isang kasabay na transaksyon ay nagbago ng parehong data dati; sa kasong ito, ang pangalawang transaksyon, kapag sinusubukang isagawa, COMMITay magtataas ng mensahe ng error at makakansela.