[go: nahoru, domu]

Пређи на садржај

Оптимистична контрола поклапања — разлика између измена

С Википедије, слободне енциклопедије
Садржај обрисан Садржај додат
м Разне исправке
м Renamed template
Ред 1: Ред 1:
{{Loš seminarski}}
{{Neprovereni seminarski}}
{{МАТФИТ2016}}
{{МАТФИТ2016}}
'''Оптимистична контрола поклапања''' ('''ОКП''') је метода [[контроле поклапања]] које се примењују у трансакцијским системима као што је [[систем за управљање релационим базама података]].
'''Оптимистична контрола поклапања''' ('''ОКП''') је метода [[контроле поклапања]] које се примењују у трансакцијским системима као што је [[систем за управљање релационим базама података]].

Верзија на датум 22. децембар 2016. у 07:48

Оптимистична контрола поклапања (ОКП) је метода контроле поклапања које се примењују у трансакцијским системима као што је систем за управљање релационим базама података.

ОКП претпоставља да више трансакција често могу да се заврше без ометања међусобно. Док раде, трансакције користе податке без стицања закључавања над тим податцима.

Пре него што започне рад, свака трансакција проверава да ниједна друга трансакција није мењала податак који је читала. Ако провера открије одређене измене, тренутна трансакција се враћа уназад и може бити поново покренута.[1] ОКП је први пут предложио Х. Т. Кунг.[2]

ОКП се обично користи у окружењима са малим протоком података. Када су сукоби ретки, трансакције могу да се извршавају без трошка о закључавању и без тога да једна трансакција чека крај закључавања друге трансакције, то јасно доводи до већег протока у односу на друге методе котроле поклапања. Међутим ако је аргумент за ресурсе чест, цена поновног покретања трансакције шкоди учинку знатно, општа је мисао да друге методе контроле поклапања имају бољи учинак под овим условима. Методе базиране на закључавању ("песимистичне") такође могу да имају лош учинак зато што закључавање може драстично да ограничи ефикасно поклапање чак и кад се трајна закључавања избегну.

ОКП фазе

ОКП трансакције укључују следеће фазе:

  • Почетак: Снима временски маркер који обележава почетак трансакције.
  • Измена: Чита вредности из базе података и провизорно пише промене.
  • Потврда: Проверава да ли су друге трансакције мењале податке које је тренутна трансакција користила (читала или писала). Ово укључује и трансакције које су се завршиле након почетка тренутне трансакције и опционо, трансакције које су активне још од потврде.
  • Извршити/Повратак: Ако не долази до сукоба, све промене ће бити извршене. Ако долази до сукоба углавном се решава прекидањем трансакције иако постоје друга решења. Водите рачуна како би сте избегли ТОСТТОУ грешку, посебно ако ова фаза и претходна фаза нису изведене из једне атомичке операције.

Веб употреба

Природа HTTP-а чини закључавање непрактичним за веб кориснички интерфејс.

Уобичајено је за корисника да крене да исправља запис и онда да га остави без "поништити" или "одјава" линка (везе). Ако је закључавање коришћено, други корисници који покушају да мењају исти снимак морају да сачекају док се првом кориснику закључавање не паузира.

HTTP пружа уграђену форму ОКП-а. Метода GET враћа ETag за ресурсе тако да следећи PUT захтев користи ETag вредност у "If-Match" пољу заглавља. Док први PUT захтев успева, други захтев неће моћи зато што је вредност у "If-Match" пољу базирана на првој верзији ресурса. [3]

Неки системи за управљање базама података пружају ОКП изворно - без потребе посебног апликационог кода. За друге, апликација може провести ОКП слој изван базе да би се избегло чекање или немо преписивање записа.

У таквим случајевима формулар садржи скривено поље са оригиналном верзијом записа, временским маркером, редним бројем или токеном. Кад се пошаље, запис се упоређује са записом из базе података и ако се разликују позива се алгоритам за решавање сукоба.

Примери

  • Медијавикијине странице за уређивање користе ОКП[4]
  • Redis омогућава ОКП кроз WATCH команду[5]
  • Гуглов програм за продавницу користи ОКП[6]
  • Ruby on Rails оквир има АПИ за ОКП[7]

Референце

  1. ^ Johnson, Rohit (2003). „Common Data Access Issues”. Expert One-on-One J2EE Design and Development. Wrox Press. ISBN 0-7645-4385-7. 
  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. 

Литература

  • Kung, H. T.; Robinson, John T. (јун 1981). „On optimistic methods for concurrency control”. ACM Transactions on Database Systems. 6 (2): 213—226. doi:10.1145/319566.319567. 
  • Enterprise JavaBeans, 3.0, By Bill Burke, Richard Monson-Haefel, Chapter 16. Transactions, Section 16.3.5. Optimistic Locking, Publisher: O'Reilly, Pub Date: May 16, 2006,Print. ISBN 0-596-00978-X.
  • Hollmann, Andreas (мај 2009). „Multi-Isolation: Virtues and Limitations” (PDF). Multi-Isolation (what is between pessimistic and optimistic locking). 01069 Gutzkovpp. 30/F301.2, Dresden: Happy-Guys Software GbR. стр. 8. Приступљено 16. 5. 2013.