[go: nahoru, domu]

Pređi na sadržaj

Optimistična kontrola poklapanja

S Vikipedije, slobodne enciklopedije

Optimistična kontrola poklapanja (OKP) je metoda kontrole poklapanja koje se primenjuju u transakcijskim sistemima kao što je sistem za upravljanje relacionim bazama podataka.

OKP pretpostavlja da više transakcija često mogu da se završe bez ometanja međusobno. Dok rade, transakcije koriste podatke bez sticanja zaključavanja nad tim podatcima.

Pre nego što započne rad, svaka transakcija proverava da nijedna druga transakcija nije menjala podatak koji je čitala. Ako provera otkrije određene izmene, trenutna transakcija se vraća unazad i može biti ponovo pokrenuta.[1] OKP je prvi put predložio H. T. Kung.[2]

OKP se obično koristi u okruženjima sa malim protokom podataka. Kada su sukobi retki, transakcije mogu da se izvršavaju bez troška o zaključavanju i bez toga da jedna transakcija čeka kraj zaključavanja druge transakcije, to jasno dovodi do većeg protoka u odnosu na druge metode kotrole poklapanja. Međutim ako je argument za resurse čest, cena ponovnog pokretanja transakcije škodi učinku znatno, opšta je misao da druge metode kontrole poklapanja imaju bolji učinak pod ovim uslovima. Metode bazirane na zaključavanju ("pesimistične") takođe mogu da imaju loš učinak zato što zaključavanje može drastično da ograniči efikasno poklapanje čak i kad se trajna zaključavanja izbegnu.

OKP faze[uredi | uredi izvor]

OKP transakcije uključuju sledeće faze:

  • Početak: Snima vremenski marker koji obeležava početak transakcije.
  • Izmena: Čita vrednosti iz baze podataka i provizorno piše promene.
  • Potvrda: Proverava da li su druge transakcije menjale podatke koje je trenutna transakcija koristila (čitala ili pisala). Ovo uključuje i transakcije koje su se završile nakon početka trenutne transakcije i opciono, transakcije koje su aktivne još od potvrde.
  • Izvršiti/Povratak: Ako ne dolazi do sukoba, sve promene će biti izvršene. Ako dolazi do sukoba uglavnom se rešava prekidanjem transakcije iako postoje druga rešenja. Vodite računa kako bi ste izbegli TOSTTOU grešku, posebno ako ova faza i prethodna faza nisu izvedene iz jedne atomičke operacije.

Veb upotreba[uredi | uredi izvor]

Priroda HTTP-a čini zaključavanje nepraktičnim za veb korisnički interfejs.

Uobičajeno je za korisnika da krene da ispravlja zapis i onda da ga ostavi bez "poništiti" ili "odjava" linka (veze). Ako je zaključavanje korišćeno, drugi korisnici koji pokušaju da menjaju isti snimak moraju da sačekaju dok se prvom korisniku zaključavanje ne pauzira.

HTTP pruža ugrađenu formu OKP-a. Metoda GET vraća ETag za resurse tako da sledeći PUT zahtev koristi ETag vrednost u "If-Match" polju zaglavlja. Dok prvi PUT zahtev uspeva, drugi zahtev neće moći zato što je vrednost u "If-Match" polju bazirana na prvoj verziji resursa.[3]

Neki sistemi za upravljanje bazama podataka pružaju OKP izvorno - bez potrebe posebnog aplikacionog koda. Za druge, aplikacija može provesti OKP sloj izvan baze da bi se izbeglo čekanje ili nemo prepisivanje zapisa.

U takvim slučajevima formular sadrži skriveno polje sa originalnom verzijom zapisa, vremenskim markerom, rednim brojem ili tokenom. Kad se pošalje, zapis se upoređuje sa zapisom iz baze podataka i ako se razlikuju poziva se algoritam za rešavanje sukoba.

Primeri[uredi | uredi izvor]

Reference[uredi | uredi izvor]

  1. ^ Johnson, Rohit (2003). „Common Data Access Issues”. Expert One-on-One J2EE Design and Development. Wrox Press. ISBN 978-0-7645-4385-2. Arhivirano iz originala 08. 10. 2011. g. Pristupljeno 10. 06. 2016. 
  2. ^ Kung, H.T. (1981). „On Optimistic Methods for Concurrency Control”. ACM Transactions on Database Systems. 
  3. ^ „Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout”. W3C Note. 10. 5. 1999. 
  4. ^ Help:Edit conflict
  5. ^ „Transactions in Redis”. 
  6. ^ „The Datastore”. What Is Google App Engine?. 27. 8. 2010. 
  7. ^ „Module ActiveRecord::Locking”. Rails Framework Documentation. 

Literatura[uredi | uredi izvor]