Първо, заключването на таблица няма да попречи на друга сесия да издаде SELECT твърдения срещу данните.
В сесия 1, ако заключа масата
SQL> lock table foo in exclusive mode;
Table(s) Locked.
След това мога да започна Сесия 2 и да поискам данните, които искам
SQL> select * from foo;
COL1
----------
1
1
В Oracle писателите не блокират четци, така че никога не можете да попречите на друга сесия да запитва данните в таблица.
Звучи сякаш това, което се опитвате да приложите, е песимистично заключване. В такъв случай, вместо да заключвате таблицата, правите SELECT FOR UPDATE който заключва конкретния запис, който възнамерявате да обработите. Докато всички други сесии също се опитват да направят SELECT FOR UPDATE (в зависимост от версията на Oracle, потенциално добавяне на SKIP LOCKED квалификатор и/или WAIT квалификатор). Това заключва конкретния ред, който обработвате, и позволява на втората сесия или да избере различен ред, или да изтече време, или да открие, че няма редове за обработка в зависимост от спецификата на изпълнението. Това не включва заключване на масата.
Единственият начин заключването да бъде освободено е сесията, която го е придобила, да го освободи (обикновено чрез прекратяване на транзакцията) или сесията, която го е придобила, да бъде прекратена. Ако клиентското приложение все още работи, но не прави нищо, за да освободи заключването или да прекрати сесията, заключването ще бъде задържано за неопределено време. DBA ще трябва изрично да убие сесията, оставяйки транзакцията да се върне назад и да освободи заключването, за да накара системата да се движи отново. Ако клиентското приложение спре да работи или най-малкото спре да отговаря (все още не съм наясно точно какъв сценарий на повреда обсъждате), е възможно активирането на откриване на мъртва връзка (DCD) чрез параметър "SQLNET.EXPIRE_TIME" на ниво база данни би накарало базата данни да определи, че клиентът не реагира и автоматично да прекрати сесията, връщайки обратно транзакцията и освобождавайки заключването.
Ако обаче има множество сесии за обработка на данни, обикновено е много за предпочитане да се използва някаква форма на оптимистично заключване. В противен случай вие проектирате система, която неизбежно ще се нуждае от DBA спешно да намери и убие сесии, за да накара бизнес потребителите да работят отново и която ще изисква все повече и повече намеса, колкото по-натоварена става. Това не е нещо, което администраторите на бази данни обичат да правят и не е нещо, от което бизнес потребителите обичат да се оплакват. Една проста оптимистична заключваща схема би била нещо като
- Изберете ключ за обработка и някакъв вид дата, указваща последния път, когато редът е бил актуализиран.
- Актуализирайте колона за състояние на „обработва се“, така че други сесии да не се опитват да обработят същия ред.
- Обработете записа във вашето приложение
- Когато приключите с обработката, актуализирайте данните, като използвате ключа и часа, който сте избрали в първата стъпка. Ако актуализирате 1 ред, знаете, че никоя друга сесия не е променила въпросните данни, откакто сте ги избрали. Ако актуализирате 0 реда, знаете, че някоя друга сесия е променила данните, откакто сте ги избрали.
С този вид архитектура е сравнително лесно да се направи запитване към базата данни, за да се види кои редове се обработват и например да има задача, която задава колоната за състояние обратно на „необработена“ след известен период от време, ако клиентът не е завършен. Наистина е лесно за други сесии да изберат различен ред за обработка. И е сравнително безопасно, ако например приложението замръзне за няколко часа и след това се възстанови, тъй като то просто установи, след като приключи обработката, че друга сесия вече е обработила отново реда.
