Опит с известяване за промяна на обект в Oracle
.collapse">Съдържание
Така че защо се нуждаем от известие за промяна на обект (OCN)
Трябваше да следим промените в данните в базата данни. Решението, което първо ми дойде на ум, беше просто - актуализиране на данните в рамките на определен интервал от време (например веднъж на минута). Недостатъците на този подход са очевидни - данните може да не са се променили през избрания период и тогава просто ще заредим сървъра и канала за предаване на данни (данните, които наблюдаваме, са много обемни). Или данните ще се променят в началото на интервала от време и ние няма да знаем за това, докато времето не изтече (това не е толкова критично, но първото е доста вероятно). Като се има предвид, че може да има доста клиенти, първият минус е наистина сериозен. За щастие открихме, че Oracle предлага по-добро решение на този проблем, започвайки с версия 10g.
Как работи OCN
OCN може да работи както изключително от страната на сървъра на базата данни, така и да информира клиентското приложение чрез специален интерфейс, че наблюдаваните от него данни са се променили.
Подробности за това как работи вътрешно се намират лесно в Google; Мислех, че не е необходимо да раздувам статията с информация, която и без това е в изобилие, така че ще я опиша само накратко.
Първата стъпка е да разрешите на сървъра да използва регистрации на заявки и да разрешите използването на уведомления едно до друго. След това потребителят регистрира предупреждение. При регистрация се посочва заявка, която трябва да се наблюдава, например: След като данните в набора от резултати се променят, oracle ще уведоми клиента за това (или ще изпрати специален пакет до регистрирания ip, или ще изпълни регистрираната съхранена процедура). поддържатози механизъм е вграден в доставчика на база данни за .NET и Java. Тъй като написахме нашето приложение в .NET, аз също ще говоря по-нататък в неговия контекст (въпреки че повечето неща, с изключение на примера с код, вярвам, не зависят от това, тъй като най-интересното се случва на сървъра).
Къде без примерен код
Почти напълно взех примера от документацията, само го допълних с няколко важни точки според мен и го съкратих малко. След като кодът е написан, компилиран и програмата се изпълнява, можете да продължите и да направите нещо като:
Когато сме готови, трябва да видим това:
Ура, всичко работи! По-подробна информация можете да намерите например в документацията. По-добре е да преминете направо към това, което обикновено не е посочено в документацията - възникналите трудности.
За нашия случай нямаше толкова много минуси, че те надвишаваха плюсовете на този подход и е трудно да се нарекат някои от тях минуси, например нюанси. Струва ми се обаче, че врагът трябва да се познава по очите.
Първо, опитахме да го стартираме сами и всичко ни се получи добре. И както обикновено се случва, нищо не работи за клиента. Или по-скоро дори не излетя. Да разбера какво не е наред се оказа доста нетривиална задача. След като започнете регистрацията, можете да я видите, като изпълните специална заявка:
Е, видяхме тази регистрация веднага след създаването, но в момента, в който известието трябваше да бъде задействано, регистрационният запис просто изчезна. В регистрационните файлове, за съжаление, не можахме да намерим нищо, което да обясни това поведение. Трябваше да рискувам и да обвиня защитната стена за всичко, без да гледам. За щастие се досетихме правилно. Ето защо, първата ми препоръка - не забравяйте да проверите защитната стена и да посочите порта, когато се регистриратеизвестия.
Не всички заявки за регистрация се поддържат. Трябва да помним, че може да не е възможно да се прочетат данните в една заявка и да се окачи известие върху нея. Ако в заявката има много съединения, по-добре е да се подготвите психически за факта, че ще трябва да напишете подобна, но проста заявка. Освен това, ако регистрирате предупреждение за заявка за присъединяване, тя всъщност ще регистрира толкова много предупреждения, колкото таблици има в заявката (всяка за таблица), което може да изразходва ресурси.
За да могат уведомленията да работят по-бързо в рамките на едно и също приложение, ние разделихме на отделни класове логиката за работа с базата данни, логиката за уведомяване на нашите обекти за събития на промяна на данните и логиката за управление на двете. Благодарение на това успяхме да използваме един общ механизъм за уведомяване и да изпращаме известия вътре в приложението ръчно, без да излизаме навън (в oracle). За потребител, който работи в рамките на своята сесия и има нужда да види незабавно резултата от действията си, всичко работи добре.
Че сте прочели статията ми до този момент. Ще се радвам на всякаква обратна връзка, варираща от критика към моя код и методи за представяне на материала до емоциите, които сте изпитали в процеса на запознаване с тази технология. Ако ми разкажете за вашия опит с OCN, аз също ще бъда много щастлив и мога да добавя още малко материал към моята касичка.