{"id":30878,"date":"2019-10-31T21:37:56","date_gmt":"2019-10-31T18:37:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-i-mehanizmy-ih-kontrolya\/"},"modified":"2019-10-31T21:37:56","modified_gmt":"2019-10-31T18:37:56","slug":"tranzaktsii-i-mehanizmy-ih-kontrolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transakcije in mehanizmi njihovega nadzora","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transakcije<\/h2>\n

<\/p>\n

Transakcija je niz operacij nad podacima koji ima po\u010detak i kraj.<\/h4>\n

\nTransakcija je sekvencijalno izvr\u0161avanje operacija \u010ditanja i pisanja. Kraj transakcije mo\u017ee biti ili o\u010duvanje promena (potvrda, commit) ili poni\u0161tavanje promena (rollback). U kontekstu baza podataka, transakcija se sastoji od vi\u0161e zahteva koji se tretiraju kao jedinstven zahtev.<\/p>\n

Transakcije moraju zadovoljiti ACID svojstva.<\/h4>\n

\nAatomarnost. Transakcija se ili izvr\u0161ava u potpunosti ili se ne izvr\u0161ava uop\u0161te.<\/p>\n

Doslednost. Na kraju transakcije ne smiju biti naru\u0161ena ograni\u010denja koja se postavljaju na podatke (npr. constraints u bazi podataka). Doslednost podrazumeva da \u0107e sistem pre\u0107i iz jednog ispravnog stanja u drugo ispravno.<\/p>\n

Izolacija. Paralelno izvr\u0161avane transakcije ne smeju uticati jedna na drugu, na primer, menjaju\u0107i podatke koje koristi druga transakcija. Rezultat izvr\u0161enja paralelnih transakcija mora biti takav kao da su se transakcije izvr\u0161avale sekvencijalno.<\/p>\n

Postojanost. Nakon potvrde, promene ne smeju biti izgubljene.
\n<\/a><\/noindex><\/p>\n

Dnevnik transakcija.<\/h2>\n

<\/p>\n

Dnevnik \u010duva promene izvr\u0161ene transakcijama, obezbe\u0111uje atomarnost i postojanost podataka u slu\u010daju kvara sistema.<\/h4>\n

\nDnevnik sadr\u017ei vrednosti koje su podaci imali pre i posle svojih promena izvr\u0161enih transakcijom. Strategija Write-ahead log obavezuje na dodavanje u dnevnik zapisa o prethodnim vrednostima pre po\u010detka, a o kona\u010dnim nakon zavr\u0161etka transakcije. U slu\u010daju iznenadnog zaustavljanja sistema, baza podataka \u010dita dnevnik unazad i poni\u0161tava promene koje su napravile transakcije. Kada se susretne prekinuta transakcija, baza podataka je izvr\u0161ava i bele\u017ei njene promene u dnevnik. Nalaze\u0107i se u stanju u trenutku kvara, baza podataka \u010dita dnevnik unapred i vra\u0107a promene koje su napravile transakcije. Na taj na\u010din se zadr\u017eava postojanost transakcija koje su ve\u0107 bile potvr\u0111ene i atomarnost prekinutih transakcija.<\/p>\n

Jednostavno ponavljanje gre\u0161aka u transakcijama nije dovoljno za oporavak. <\/p>\n

Primer. U uporabnikovem ra\u010dunu je 500$, uporabnik pa se odlo\u010di, da jih dvigne preko bankomata. Opravljeni sta dve transakciji. Prva preveri stanje na ra\u010dunu in, \u010de je na ra\u010dunu dovolj sredstev, izda denar uporabniku. Druga od\u0161teje potrebno vsoto od stanja. Predpostavimo, da je pri\u0161lo do okvare sistema in prva operacija ni bila izvedena, druga pa je. V tem primeru ne moremo znova izdati denarja uporabniku brez vrnitve sistema v prvotno stanje s pozitivnim stanjem.<\/i><\/p>\n

Nivoji izolacije<\/h2>\n

<\/p>\n

Branje fiksnih podatkov (Read Committed)<\/h4>\n

\nTe\u017eava umazanega branja (Dirty Read) je v tem, da lahko transakcija prebere vmesni rezultat dela druge transakcije.<\/p>\n

Primer. Za\u010detna vrednost stanja ra\u010duna je 0$. T1 doda 50$ k stanju. T2 prebere vrednost stanja (50$). T1 prekli\u010de spremembe in se zaklju\u010di. T2 nadaljuje izvajanje z napa\u010dnimi podatki o stanju.<\/i><\/p>\n

Re\u0161itev je branje fiksnih podatkov (Read Committed), ki prepoveduje branje podatkov, spremenjenih s transakcijo. \u010ce je transakcija A spremenila nek nabor podatkov, mora transakcija B pri dostopu do teh podatkov po\u010dakati na zaklju\u010dek transakcije A.<\/p>\n

Ponovljivo branje (Repeatable Read)<\/h4>\n

\nTe\u017eava izgubljenih sprememb (Lost Updates). T1 shranjuje spremembe preko sprememb T2.<\/p>\n

Primer. Za\u010detna vrednost stanja ra\u010duna je 0$ in dve transakciji hkrati dopolnjujeta stanje. T1 in T2 prebereta stanje, ki je enako 0$. Nato T2 doda 200$ k 0$ in shrani rezultat. T1 doda 100$ k 0$ in shrani rezultat. Kon\u010dni rezultat je 100$ namesto 300$.<\/i><\/p>\n

Te\u017eava neponovljivega branja (Unrepeatable Read). Ponovno branje istih podatkov vrne razli\u010dne vrednosti.<\/p>\n

Primer. T1 prebere vrednost stanja, ki je enaka 0$. Nato T2 doda 50$ k stanju in se zaklju\u010di. T1 ponovno prebere podatke in odkrije neskladje s prej\u0161njim rezultatom.<\/i><\/p>\n

Ponovljivo branje (Repeatable Read) zagotavlja, da bo ponovno branje vrnilo enak rezultat. Podatke, ki jih prebere ena transakcija, je prepovedano spreminjati v drugih do zaklju\u010dka transakcije. \u010ce je transakcija A prebrala nek nabor podatkov, mora transakcija B pri dostopu do teh podatkov po\u010dakati na zaklju\u010dek transakcije A.<\/p>\n

Urejeno branje (Serializable)<\/h4>\n

\nProblem fanomskega branja (Phantom Reads). Dve poizvedbi, ki izbirata podatke po nekem pogoju, vra\u010data razli\u010dne vrednosti.<\/p>\n

Primer. T1 zahteva \u0161tevilo vseh uporabnikov, katerih stanje je ve\u010dje od 0$ in manj\u0161e od 100$. T2 od\u0161teje 1$ uporabniku s stanjem 101$. T1 izvede poizvedbo znova.<\/i><\/p>\n

Urejeno branje (Serializable). Transakcije se izvajajo kot popolnoma zaporedne. Prepovedano je posodabljati in dodajati zapise, ki ustrezajo pogojem poizvedbe. \u010ce je transakcija A zahtevala podatke celotne tabele, se tabela v celoti zamrzne za druge transakcije do zaklju\u010dka transakcije A.<\/p>\n

Na\u010drtovalnik (Scheduler)<\/h2>\n

<\/p>\n

Dolo\u010da zaporedje, v katerem se izvajajo operacije pri hkratnih transakcijah<\/h4>\n

\nZagotavlja dolo\u010deno raven izolacije. \u010ce rezultat izvajanja operacij ni odvisen od njihovega zaporedja, so tak\u0161ne operacije komutativne (Permutable). Komutativne so bralne operacije in operacije nad razli\u010dnimi podatki. Bralne-pisalne in pisalne-pisalne operacije niso komutativne. Naloga na\u010drtovalnika je, da izmenjuje operacije, ki jih izvajajo hkratne transakcije, tako, da je rezultat izvajanja enak zaporednemu izvajanju transakcij.<\/p>\n

Mehanizmi nadzora hkratnih nalog (Concurrency Control)<\/h2>\n

<\/p>\n

Optimizirani temelji na odkrivanju in re\u0161evanju konfliktov, pesimisti\u010dni pa na prepre\u010devanju nastanka konfliktov.<\/h4>\n

\nPri optimisti\u010dnem pristopu ve\u010d uporabnikov dobi kopije podatkov. Prvi, ki dokon\u010da urejanje, shrani spremembe, ostali pa morajo izvesti zdru\u017eitev sprememb. Optimiziran algoritem omogo\u010da, da pride do konflikta, vendar se mora sistem okrevati po konfliktnem dogodku.<\/p>\n

Pri pesimisti\u010dnem pristopu prvi uporabnik, ki pridobi podatke, prepre\u010duje dostop do podatkov drugim. \u010ce so konflikti redki, je razumno izbrati optimisti\u010dno strategijo, saj ta zagotavlja vi\u0161jo raven paralelizma.<\/p>\n

Zaklepanje (Locking)<\/h2>\n

<\/p>\n

\u010ce ena transakcija zaklene podatke, morajo ostale transakcije ob interakciji s podatki po\u010dakati na odklepanje.<\/h4>\n

\nBlok lahko obremeni bazo podatkov, tabelo, vrstico ali atribut. Skupna zaklenitev (Shared Lock) lahko obstaja na istih podatkih z ve\u010d transakcijami, kar omogo\u010da vsem transakcijam (vklju\u010dno s tisto, ki je nalagala) branje, onemogo\u010da pa spreminjanje in monopolno zaklepanje. Monopolna zaklenitev (Exclusive Lock) je lahko nalagana le z eno transakcijo, dovoljuje vsa dejanja nalagajo\u010de transakcije, drugim pa prepoveduje vse akcije.<\/p>\n

Mehanska blokada se \u0161teje za situacijo, ko so transakcije v stanju \u010dakajo\u010dega, ki traja neskon\u010dno dolgo.<\/h4>\n

\nPrimer. Prva transakcija \u010daka na sprostitev podatkov, ki jih je zasedla druga, medtem ko druga \u010daka na sprostitev podatkov, zasedenih s prvo.<\/i><\/p>\n

Optimizacijska re\u0161itev problema mehanske blokade omogo\u010da, da do mehanske blokade pride, nato pa sistem obnovi z vra\u010danjem ene od transakcij, vklju\u010denih v mehansko blokado.<\/h4>\n

\nIskanje mehanskih blokad poteka ob dolo\u010denih \u010dasovnih intervalih. Eden od na\u010dinov za odkrivanje je \u010dasovni, kar pomeni, da \u0161teje, da je pri\u0161lo do mehanske blokade, \u010de transakcija izvaja predolgo. Ko se mehanska blokada najde, se ena od transakcij vrne nazaj, kar omogo\u010da drugim transakcijam, vklju\u010denim v mehansko blokado, da se kon\u010dajo. Izbira \u017ertve je lahko temelji na stro\u0161kih transakcij ali njihovem vrstnem redu (Wait-Die in Wound-wait sheme). <\/p>\n

Vsaki transakciji T<\/b> je dodeljena \u010dasovna oznaka TS<\/b> ki vsebuje \u010das za\u010detka izvajanja transakcije.<\/p>\n

Wait-Die. <\/p>\n

\u0415\u0441\u043b\u0438 TS(Ti)<\/b> < TS(Tj)<\/b>, potem Ti<\/b> \u010daka, druga\u010de Ti<\/b> se vrne nazaj in za\u010dne znova s to isto \u010dasovno oznako.<\/u><\/p>\n

\u010ce mlaj\u0161a transakcija zasede vir in starej\u0161a zahteva isti vir, je starej\u0161i transakciji dovoljeno \u010dakati. \u010ce starej\u0161a transakcija zasede vir, bo mlaj\u0161a transakcija, ki zahteva ta vir, vrnjena nazaj.<\/p>\n

Wound-wait. <\/p>\n

\u0415\u0441\u043b\u0438 TS(Ti)<\/b> < TS(Tj)<\/b>, potem Tj<\/b> se vrne nazaj in za\u010dne znova s to isto \u010dasovno oznako, druga\u010de Ti<\/b> \u010daka.<\/u><\/p>\n

\u010ce mlaj\u0161a transakcija prevzame vir, medtem ko starej\u0161a transakcija zahteva isti vir, bo mlaj\u0161a transakcija prekinjena. \u010ce starej\u0161a transakcija prevzame vir, je mlaj\u0161i transakciji, ki zahteva ta vir, dovoljena, da \u010daka. Izbira \u017ertve na podlagi starosti prepre\u010duje nastanek mrtvih to\u010dk, vendar prekinja transakcije, ki niso v stanju mrtve to\u010dke. Te\u017eava je v tem, da se transakcije lahko prekinejo ve\u010dkrat, saj starej\u0161a transakcija lahko dolgo obdr\u017ei vir.<\/p>\n

Pesimisti\u010dna re\u0161itev te\u017eave z mrtvimi to\u010dkami ne dovoli, da transakcija za\u010dne izvajanje, \u010de obstaja tveganje nastanka mrtve to\u010dke.<\/h4>\n

\nZa odkrivanje mrtvih to\u010dk se gradi graf (graf \u010dakanja, wait-for-graph), kjer so vozli\u0161\u010da transakcije, robovi pa so usmerjeni od transakcij, ki \u010dakajo na osvoboditev podatkov, do transakcij, ki so te podatke prevzele. Mrtva to\u010dka se \u0161tejemo, \u010de graf vsebuje zanke. Izgradnja grafa \u010dakanja je \u0161e posebej draga operacija v porazdeljenih podatkovnih bazah.<\/p>\n

Dvojna blokada \u2014 prepre\u010devanje mrtvih to\u010dk s tem, da transakcija na za\u010detku prevzame vse vire, ki jih potrebuje, in jih sprosti na koncu.<\/h4>\n

\nVse blokirne operacije morajo predhoditi prvi razburljivi operaciji. Ima dve fazi \u2014 fazo rasti (Growing Phase), kjer se kumulirajo prevzemi, in fazo kr\u010denja (Shrinking Phase), kjer se spro\u0161\u010dajo prevzemi. V primeru, da enega od virov ni mogo\u010de prevzeti, se transakcija za\u010dne znova. Lahko se zgodi, da transakcija ne bo mogla prevzeti zahtevanih virov, na primer, \u010de ve\u010d transakcij tekmuje za iste vire.<\/p>\n

Dvojni commit zagotavlja izvedbo commit-a na vseh replikah podatkovne baze.<\/h4>\n

\nVsaka podatkovna baza vnese informacije o podatkih, ki bodo spremenjeni, v dnevnik in odgovori koordinatorju z OK (Voting Phase). Ko vsi odgovorijo z OK, koordinator po\u0161lje signal, ki vse obvezuje k izvedbi commita. Po commitu stre\u017enika<\/a> odgovorijo z OK, \u010de vsaj eden ne odgovori z OK, koordinator po\u0161lje signal za preklic sprememb vsem stre\u017enikom (Completion Phase).<\/p>\n

Metoda \u010dasovnih \u017eigov<\/h2>\n

<\/p>\n

Starej\u0161a transakcija se prekine, ko posku\u0161a dostopati do podatkov, ki jih uporablja mlaj\u0161a transakcija.<\/h4>\n

\nVsaki transakciji je dodeljen \u010dasovni \u017eig TS<\/b> ki ustreza za\u010detku njenega izvajanja. \u010ce je Ti<\/b> starej\u0161i Tj<\/b>, potem TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Ko se transakcija vrne, ji je dodeljen nov \u010dasovni \u017eig. Vsak podatek Q<\/b> vklju\u010den v transakcijo je ozna\u010den z dvema \u017eigoma. W-TS(Q)<\/b> \u2014 \u010dasovni \u017eig najmlaj\u0161e transakcije, ki je uspe\u0161no zapisala Q<\/b>. R-TS(Q)<\/b> \u2014 \u010dasovni \u017eig najmlaj\u0161e transakcije, ki je izvedla operacijo branja nad Q<\/b>.<\/p>\n

Ko transakcija T<\/b> zahteva branje podatkov Q<\/b> so na voljo dve mo\u017enosti.<\/p>\n

\u0415\u0441\u043b\u0438 TS(T)<\/b> < W-TS(Q)<\/b>, to je, \u010de so bili podatki posodobljeni s strani mlaj\u0161e transakcije, se transakcija T<\/b> vrne.<\/u><\/p>\n

\u0415\u0441\u043b\u0438 TS(T)<\/b> >= W-TS(Q)<\/b>, branje pa se izvede in R-TS(Q)<\/b> ustvarjanje storitev, ki bodo poenostavile delo z multioblakom. Ena od podjetij, ki se razvijajo na tem podro\u010dju, je VMware. MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Ko transakcija T<\/b> zahteva spremembo podatkov Q<\/b> so na voljo dve mo\u017enosti. <\/p>\n

\u0415\u0441\u043b\u0438 TS(T)<\/b> < R-TS(Q)<\/b>, to je, \u010de so bili podatki \u017ee prebrani s strani mlaj\u0161e transakcije in \u010de pride do spremembe, bo nastal konflikt. Transakcija T<\/b> vrne. <\/u><\/p>\n

\u0415\u0441\u043b\u0438 TS(T)<\/b> < W-TS(Q)<\/b>, to je, \u010de transakcija posku\u0161a prepisati novej\u0161o vrednost, se transakcija T vrne. V ostalih primerih se sprememba izvede in W-TS(Q)<\/b> postane enaka TS(T)<\/b>.<\/u><\/p>\n

Ni potrebno drago graditi grafa \u010dakanja. Starej\u0161e transakcije so odvisne od novej\u0161ih, zato v grafu \u010dakanja ni ciklov. Ni mrtvih blokad, saj transakcije ne \u010dakajo, ampak se takoj vrnejo. Mo\u017eni so kaskadni povratki. \u010ce Ti<\/b> se vrne, in Tj<\/b> je prebrala podatke, ki jih je spremenila Ti<\/b>, potem Tj<\/b> prav tako mora vrniti. \u010ce je pri tem Tj<\/b> \u017ee bila potrjena, bo pri\u0161lo do kr\u0161itve na\u010dela trajnosti.<\/p>\n

Ena od re\u0161itev kaskadnih povratkov. Transakcija izvede vse operacije zapisa na koncu, pri \u010demer morajo druge transakcije \u010dakati na zaklju\u010dek te operacije. Transakcije \u010dakajo na potrditev pred branjem.<\/p>\n

Thomasova pravila pisanja \u2014 variacija metode \u010dasovnih \u017eigov, pri kateri so podatki, ki jih je posodobil mlaj\u0161a transakcija, prepovedani za prepis s staro<\/h4>\n

\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30878","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Transakcije in mehanizmi njihovega nadzora | ProHoster","description":"Transakcije Transakcija je zaporedje operacij nad podatki, ki ima za\u010detek in konec. Transakcija je zaporedno izvajanje operacij branja in zapisovanja.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0438 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0438\u0445 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f | ProHoster","og:description":"\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:56+00:00","article:modified_time":"2019-10-31T18:37:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:38","updated":"2026-02-22 15:31:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransakcija T<\/b> zahteva spremembo podatkov Q<\/b>. \u0415\u0441\u043b\u0438 TS(T)<\/b> < W-TS(Q)<\/b>, to je, \u010de transakcija posku\u0161a prepisati novej\u0161o vrednost, se transakcija T ne vrne, kot v metodi \u010dasovnih \u017eigov.
\n
Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"