{"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\/hr\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transakcije i mehanizmi njihove kontrole","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transakcije<\/h2>\n

<\/p>\n

Transakcija je niz operacija nad podacima koja ima po\u010detak i kraj<\/h4>\n

\nTransakcija je sekvencijalno izvo\u0111enje operacija \u010ditanja i pisanja. Kraj transakcije mo\u017ee biti ili spremanje promjena (potvrda, commit) ili poni\u0161tavanje promjena (rollback). U kontekstu baza podataka, transakcija je nekoliko upita koji se tretiraju kao jedinstveni upit.<\/p>\n

Transakcije moraju zadovoljavati ACID svojstva<\/h4>\n

\nAtomarnost. Transakcija se izvede ili potpuno ili se ne izvr\u0161i uop\u0107e.<\/p>\n

Dosljednost. Kada se transakcija zavr\u0161i, ograni\u010denja nametnuta na podatke ne smiju biti naru\u0161ena (na primjer, constraints u bazi podataka). Dosljednost podrazumijeva da \u0107e sustav biti preba\u010den iz jednog ispravnog stanja u drugo ispravno.<\/p>\n

Izoliranost. Paralelno izvo\u0111ene transakcije ne smiju utjecati jedna na drugu, na primjer, mijenjati podatke koje koristi druga transakcija. Rezultat izvr\u0161avanja paralelnih transakcija trebao bi biti kao da su transakcije izvr\u0161ene sekvencijalno.<\/p>\n

Trajnost. Nakon potvrde, promjene ne smiju biti izgubljene.
\n<\/a><\/noindex><\/p>\n

Zapisnik transakcija<\/h2>\n

<\/p>\n

Zapisnik pohranjuje promjene koje su izvr\u0161ene transakcijama, osigurava atomarnost i trajnost podataka u slu\u010daju kvara sustava<\/h4>\n

\nZapisnik sadr\u017ei vrijednosti koje su podaci imali prije i nakon promjene transakcijom. Strategija Write-ahead log obvezuje dodavanje zapisa o prethodnim vrijednostima prije po\u010detka, a o kona\u010dnim nakon zavr\u0161etka transakcije. U slu\u010daju iznenadne pauze sustava, baza podataka \u010dita log obrnutim redoslijedom i poni\u0161tava promjene napravljene transakcijama. U slu\u010daju prekinute transakcije, baza podataka \u0107e je izvr\u0161iti i unijeti promjene u zapisnik. U stanju u kojem je bila u trenutku kvara, baza podataka \u010dita log u pravom redoslijedu i vra\u0107a promjene napravljenih transakcijama. Tako se osigurava trajnost transakcija koje su ve\u0107 bile potvr\u0111ene i atomarnost prekinute transakcije.<\/p>\n

Jednostavno ponavljanje neispravnih transakcija nije dovoljno za oporavak. <\/p>\n

Primjer. Na ra\u010dunu korisnika je 500$ i korisnik odlu\u010duje podi\u0107i ih putem bankomata. Izvode se dvije transakcije. Prva \u010dita stanje na ra\u010dunu, i ako ima dovoljno sredstava, ispla\u0107uje novac korisniku. Druga oduzima potrebni iznos od stanja. Pretpostavimo da je do\u0161lo do kvara sustava i prva operacija se nije izvr\u0161ila, dok se druga izvr\u0161ila. U tom slu\u010daju ne mo\u017eemo ponovno isplatiti novac korisniku bez vra\u0107anja sustava u izvorno stanje s pozitivnim saldom.<\/i><\/p>\n

Razine izolacije<\/h2>\n

<\/p>\n

\u010citanje potvr\u0111enih podataka (Read Committed)<\/h4>\n

\nProblem prljavog \u010ditanja (Dirty Read) se sastoji u tome da transakcija mo\u017ee pro\u010ditati me\u0111urezultate rada druge transakcije.<\/p>\n

Primjer. Po\u010detna vrijednost salda 0$. T1 dodaje 50$ na saldo. T2 \u010dita saldo (50$). T1 odbacuje promjene i zavr\u0161ava. T2 nastavlja s izvr\u0161avanjem s pogre\u0161nim podacima o saldu.<\/i><\/p>\n

Rje\u0161enje je \u010ditanje potvr\u0111enih podataka (Read Committed) koje zabranjuje \u010ditanje podataka koji su promijenjeni transakcijom. Ako je transakcija A promijenila odre\u0111eni skup podataka, tada je transakcija B pri poku\u0161aju pristupa tim podacima primorana \u010dekati zavr\u0161etak transakcije A.<\/p>\n

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

\nProblem izgubljenih promjena (Lost Updates). T1 sprema promjene preko promjena T2.<\/p>\n

Primjer. Po\u010detna vrijednost salda 0$ i dvije transakcije istovremeno dopunjuju saldo. T1 i T2 \u010ditaju saldo koji iznosi 0$. Zatim T2 dodaje 200$ na 0$ i sprema rezultat. T1 dodaje 100$ na 0$ i sprema rezultat. Krajni rezultat je 100$ umjesto 300$.<\/i><\/p>\n

Problem neopetljivog \u010ditanja (Unrepeatable read). Ponovno \u010ditanje istih podataka vra\u0107a razli\u010dite vrijednosti.<\/p>\n

Primjer. T1 \u010dita vrijednost salda koja iznosi 0$. Zatim T2 dodaje 50$ na saldo i zavr\u0161ava. T1 ponovno \u010dita podatke i otkriva neslaganje s prethodnim rezultatom.<\/i><\/p>\n

Ponovljivo \u010ditanje (Repeatable Read) jam\u010di da \u0107e ponovno \u010ditanje dati isti rezultat. Podaci pro\u010ditani od strane jedne transakcije ne smiju se mijenjati u drugim sve do zavr\u0161etka transakcije. Ako je transakcija A pro\u010ditala odre\u0111eni skup podataka, tada je transakcija B pri poku\u0161aju pristupa tim podacima primorana \u010dekati zavr\u0161etak transakcije A.<\/p>\n

Poredano \u010ditanje (Serializable)<\/h4>\n

\nProblem fantomskog \u010ditanja (Phantom Reads). Dva upita koja odabiru podatke prema odre\u0111enom uvjetu vra\u0107aju razli\u010dite vrijednosti.<\/p>\n

Primjer. T1 tra\u017ei broj svih korisnika \u010diji je saldo ve\u0107i od 0$ ali manji od 100$. T2 oduzima 1$ od korisnika sa saldom od 101$. T1 ponovo izvr\u0161ava upit.<\/i><\/p>\n

Poredano \u010ditanje (Serializable). Transakcije se izvode kao potpuno sekvencijalne. Zabranjeno je a\u017eurirati i dodavati zapise koji podlije\u017eu uvjetima upita. Ako je transakcija A zatra\u017eila podatke iz cijele tablice, tada se tablica potpuno zamrzava za ostale transakcije do zavr\u0161etka transakcije A.<\/p>\n

Planer (Scheduler)<\/h2>\n

<\/p>\n

Postavlja redoslijed u kojem se operacije trebaju izvr\u0161avati tijekom paralelnih transakcija.<\/h4>\n

\nOsigurava zadanu razinu izolacije. Ako rezultat izvr\u0161avanja operacija ne ovisi o njihovom redoslijedu, takve su operacije komutativne (Permutable). Komutativne su operacije \u010ditanja i operacije nad razli\u010ditim podacima. Operacije \u010ditanja-upisa i upisa-upisa nisu komutativne. Zadatak planera je naizmjeni\u010dno raspore\u0111ivati operacije koje izvode paralelne transakcije tako da je rezultat izvr\u0161avanja ekvivalentan sekvencijalnom izvr\u0161avanju transakcija.<\/p>\n

Mehanizmi kontrole paralelnih zadataka (Concurrency Control)<\/h2>\n

<\/p>\n

Optimisti\u010dki se temelji na otkrivanju i rje\u0161avanju sukoba, pesimisti\u010dki na sprje\u010davanju nastanka sukoba.<\/h4>\n

\nKod optimisti\u010dkog pristupa vi\u0161e korisnika dobiva kopije podataka. Prvi koji zavr\u0161i s ure\u0111ivanjem sprema promjene, ostali moraju izvr\u0161iti spajanje promjena. Optimisti\u010dki algoritam dopu\u0161ta sukob, ali sustav se mora oporaviti nakon sukoba.<\/p>\n

Kod pesimisti\u010dkog pristupa prvi korisnik koji zauzme podatke sprje\u010dava pristup podacima ostalima. Ako su sukobi rijetki, razumno je odabrati optimisti\u010dku strategiju jer ona omogu\u0107ava vi\u0161u razinu paralelizma.<\/p>\n

Zaklju\u010davanje (Locking)<\/h2>\n

<\/p>\n

Ako jedna transakcija zaklju\u010dava podatke, ostale transakcije prilikom pristupa podacima moraju \u010dekati otklju\u010davanje.<\/h4>\n

\nBlok se mo\u017ee postaviti na bazu podataka, tablicu, red ili atribut. Zajedni\u010dko zaklju\u010davanje (Shared Lock) mo\u017ee se primijeniti na iste podatke od strane vi\u0161e transakcija, dozvoljavaju\u0107i svim transakcijama (uklju\u010duju\u0107i onu koja je postavila) \u010ditanje, ali zabranjuje izmjenu i ekskluzivno zaklju\u010davanje. Ekskluzivno zaklju\u010davanje (Exclusive Lock) mo\u017ee se postaviti samo od strane jedne transakcije, dozvoljavaju\u0107i sve radnje transakcije koja ga je postavila, a zabranjuje sve radnje ostalim.<\/p>\n

Situacija u kojoj se transakcije nalaze u stanju \u010dekanja koje traje beskona\u010dno dugo smatra se me\u0111usobnim blokiranjem.<\/h4>\n

\nPrimjer. Prva transakcija \u010deka osloba\u0111anje podataka koje druga transakcija dr\u017ei, dok druga \u010deka osloba\u0111anje podataka koje prva dr\u017ei.<\/i><\/p>\n

Optimizirano rje\u0161enje za problem me\u0111usobnog blokiranja dopu\u0161ta da do njega do\u0111e, ali zatim obnavlja sustav poni\u0161tavaju\u0107i jednu od transakcija uklju\u010denih u me\u0111usobno blokiranje.<\/h4>\n

\nS odre\u0111enom frekvencijom provodi se pretra\u017eivanje za me\u0111usobna blokiranja. Jedan od na\u010dina otkrivanja je vremenski, tj. smatra se da je do\u0161lo do me\u0111usobnog blokiranja ako transakcija traje predugo. Kada se otkrije me\u0111usobno blokiranje, jedna od transakcija se poni\u0161tava, omogu\u0107avaju\u0107i drugim transakcijama uklju\u010denim u blokiranje da zavr\u0161e. Odabir \u017ertve mo\u017ee se temeljiti na tro\u0161ku transakcija ili njihovom starijem statusu (Wait-Die i Wound-wait sheme). <\/p>\n

Svakoj transakciji T<\/b> dodjeljuje se vremenska oznaka TS<\/b> koja sadr\u017ei vrijeme po\u010detka izvr\u0161avanja transakcije.<\/p>\n

Wait-Die. <\/p>\n

Ako TS(Ti)<\/b> < TS(Tj)<\/b>, tada Ti<\/b> \u010deka, ina\u010de Ti<\/b> se poni\u0161tava i po\u010dinje iznova s istom vremenskom oznakom.<\/u><\/p>\n

Ako mla\u0111a transakcija dr\u017ei resurs, a starija zahtijeva isti resurs, starijoj transakciji je dozvoljeno \u010dekati. Ako starija transakcija dr\u017ei resurs, mla\u0111a transakcija koja zahtijeva taj resurs \u0107e biti poni\u0161tena.<\/p>\n

Wound-wait. <\/p>\n

Ako TS(Ti)<\/b> < TS(Tj)<\/b>, tada Tj<\/b> se poni\u0161tava i po\u010dinje iznova s istom vremenskom oznakom, ina\u010de Ti<\/b> \u010deka.<\/u><\/p>\n

Ako je mla\u0111a transakcija zauzela resurs, a starija transakcija tra\u017ei taj isti resurs, mladja transakcija \u0107e biti otkazana. Ako je starija transakcija zauzela resurs, mla\u0111oj transakciji koja tra\u017ei taj resurs je dopu\u0161teno \u010dekati. Odabir \u017ertve na osnovu starosti spre\u010dava pojavu me\u0111usobnih blokada, ali otkazuje transakcije koje nisu u stanju me\u0111usobnog blokiranja. Problem je u tome \u0161to se transakcije mogu otkazivati vi\u0161e puta, jer starija transakcija mo\u017ee dugo zadr\u017eavati resurs.<\/p>\n

Pesimisti\u010dno re\u0161enje problema me\u0111usobnih blokada ne dopu\u0161ta transakciji da zapo\u010dne izvr\u0161avanje ako postoji rizik od pojave me\u0111usobne blokade.<\/h4>\n

\nZa otkrivanje me\u0111usobne blokade gradi se graf (graf \u010dekanja, wait-for-graph), \u010dvorovi su transakcije, a grane su usmerene od transakcija koje \u010dekaju osloba\u0111anje podataka ka transakcijama koje su zauzele te podatke. Smatra se da je do\u0161lo do me\u0111usobne blokade ako graf ima cikli\u010dnost. Gradnja grafova \u010dekanja, posebno u distribuiranim BDP-ima, je skupa procedura.<\/p>\n

Dvostruka blokada - spre\u010davanje me\u0111usobnih blokada tako \u0161to se svi resursi koje koristi transakcija zauzimaju na po\u010detku transakcije i osloba\u0111aju na kraju.<\/h4>\n

\nSve blokiraju\u0107e operacije moraju prethoditi prvoj operaciji otpu\u0161tanja. Ima dve faze - Faza rasta u kojoj se akumuliraju zauzimanja i Faza smanjenja u kojoj se osloba\u0111aju zauzimanja. U slu\u010daju nemogu\u0107nosti zauzimanja jednog od resursa, transakcija po\u010dinje ispo\u010detka. Mo\u017ee do\u0107i do situacije kada transakcija ne mo\u017ee zauzeti potrebne resurse, na primer, ako vi\u0161e transakcija konkuri\u0161e za iste resurse.<\/p>\n

Dvostruko potvr\u0111ivanje osigurava izvr\u0161enje potvrde na svim replikama BDP-a.<\/h4>\n

\nSvaka BDP unosi informacije o podacima koji \u0107e biti promenjeni u log i odgovara koordinatorki sa OK (Faza glasanja). Nakon \u0161to svi odgovore sa OK, koordinator \u0161alje signal koji obavezuje sve da izvr\u0161e potvrdu. Nakon potvrde poslu\u017eitelja<\/a> odgovaraju sa OK, ako barem jedan ne odgovori sa OK, koordinator \u0161alje signal za povla\u010denje svih promena svim serverima (Faza zavr\u0161etka).<\/p>\n

Metod vremenskih oznaka<\/h2>\n

<\/p>\n

Starija transakcija se otkazuje prilikom poku\u0161aja pristupanja podacima koji su uklju\u010deni mla\u0111om transakcijom<\/h4>\n

\nSvakoj transakciji dodjeljuje se vremenska oznaka TS<\/b> koja odgovara vremenu po\u010detka izvr\u0161avanja. Ako Ti<\/b> je starija Tj<\/b>, tada TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Kada se transakcija poni\u0161ti, dodjeljuje joj se nova vremenska oznaka. Svaki objekt podataka Q<\/b> uklju\u010den u transakciju ozna\u010dava se s dvije oznake. W-TS(Q)<\/b> \u2014 vremenska oznaka najmla\u0111e transakcije koja je uspje\u0161no izvr\u0161ila zapis preko Q<\/b>. R-TS(Q)<\/b> \u2014 vremenska oznaka najmla\u0111e transakcije koja je izvr\u0161ila zapis \u010ditanja preko Q<\/b>.<\/p>\n

Kada transakcija T<\/b> tra\u017ei \u010ditanje podataka Q<\/b> postoje dvije mogu\u0107nosti.<\/p>\n

Ako TS(T)<\/b> < W-TS(Q)<\/b>, tj. ako su podaci a\u017eurirani od strane mladije transakcije, tada se transakcija T<\/b> poni\u0161tava.<\/u><\/p>\n

Ako TS(T)<\/b> >= W-TS(Q)<\/b>, tada se \u010ditanje izvr\u0161ava i R-TS(Q)<\/b> postaje MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Kada transakcija T<\/b> tra\u017ei promjenu podataka Q<\/b> postoje dvije mogu\u0107nosti. <\/p>\n

Ako TS(T)<\/b> < R-TS(Q)<\/b>, tj. ako su podaci ve\u0107 bili pro\u010ditani od strane mladije transakcije, a ako se izvr\u0161i promjena, do\u0107i \u0107e do sukoba. Transakcija T<\/b> poni\u0161tava. <\/u><\/p>\n

Ako TS(T)<\/b> < W-TS(Q)<\/b>, tj. ako transakcija poku\u0161ava prepisati noviju vrijednost, transakcija T se poni\u0161tava. U ostalim slu\u010dajevima promjena se izvr\u0161ava i W-TS(Q)<\/b> postaje jednako TS(T)<\/b>.<\/u><\/p>\n

Nije potrebno skupo gra\u0111enje grafa \u010dekanja. Starije transakcije ovise o novijima, stoga u grafu \u010dekanja nema ciklusa. Nema me\u0111usobnih blokada, budu\u0107i da transakcije ne \u010dekaju, ve\u0107 odmah poni\u0161tavaju. Mogu\u0107i su kaskadni poni\u0161taji. Ako Ti<\/b> se poni\u0161ti, a Tj<\/b> je pro\u010ditala podatke koje je promijenila Ti<\/b>, tada Tj<\/b> ona tako\u0111er mora biti poni\u0161tena. Ako je pritom Tj<\/b> ve\u0107 bila potvr\u0111ena, do\u0107i \u0107e do kr\u0161enja na\u010dela stabilnosti.<\/p>\n

Jedno od rje\u0161enja za kaskadne poni\u0161taje. Transakcija izvr\u0161ava sve operacije zapisa na kraju, a druge transakcije moraju \u010dekati zavr\u0161etak te operacije. Transakcije \u010dekaju potvrdu prije \u010ditanja.<\/p>\n

Thomasova pravila za pisanje - varijacija metode vremenskih oznaka prema kojoj podaci a\u017eurirani od strane mladije transakcije ne mogu se prepisivati starijom<\/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 i mehanizmi njihove kontrole | ProHoster","description":"Transakcija je niz operacija nad podacima koji ima po\u010detak i kraj. Transakcija je sekvencijalno izvr\u0161avanje operacija \u010ditanja i pisanja.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransakcija T<\/b> tra\u017ei promjenu podataka Q<\/b>. Ako TS(T)<\/b> < W-TS(Q)<\/b>, tj. ako transakcija poku\u0161ava prepisati noviju vrijednost, transakcija T se ne poni\u0161tava kao u metodi vremenskih oznaka.
\n
Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"