Specifika technologie Oracle Forms
Technologie Oracle Forms je určená pro vývoj OLTP aplikací
nad databází Oracle (primárně pořizování dat do DB). Z tohoto důvodu je
technologie optimalizovaná na vysoký uživatelský komfort při této činnosti
(bohaté uživatelské rozhraní + uživatelsky přívětivé řešení kolizí
z mutliuživatelského přístupu k DB).
Z pohledu práce s databází je jedno, v jaké
verzi Oracle Forms je aplikace provozována. Tlustý klient 6i i tenký klient 6i,
9i, 10g, 11g a 12c pracují s databází shodně
a to:
a to:
- Autentizace je realizována přímo prostředky DB – tj. aplikační uživatel je přímo založen jako uživatel v DB a autentizuje se vůči DB (typicky uživatelským jménem a heslem).
- Každý uživatel má svojí vyhrazenou DB session po celou dobu práce s aplikací.
- Autorizace je realizována systémem rolí v DB Oracle.
- Transaction Isolation Level je defaultně nastaven na Read Commited.
- Pro zamykání dat se využívá pesimistické zamykání (konstrukce SELECT … FOR UPDATE NOWAIT) a to vždy hned při pokusu o změnu dat, tj. od této doby až do commit/rollback trvá zámek v databázi. Zámky jsou vždy ROW LEVEL, tj. zamykají se vždy jen změněné/mazané řádky. Toto je výchozí nastavení každého DB bloku v Oracle Forms, které je možné deklarativně změnit na pesimistické zamykání až ve chvíli odesílání změněných dat do databáze.
- Pro detekci změny nebo smazání záznamu jinou DB session je využíván mechanizmus, kdy se při pesimistickém zamykání záznamu vyberou z DB aktuální hodnoty všech databázových polí ve formuláři a poté dojde k porovnání těchto DB hodnot s hodnotami ve formuláři. Pokud se hodnoty neshodují, vypíše se chyba a změna/smazání dat není povolena (nutno provést requery dat z databáze).
- SQL příkazy generované do databáze používají defaultně pro identifikaci řádků pseudosloupec ROWID. Variantně může být využito identifikace přes primární klíč.
Moderní technologie
Moderní technologie založené na responsivním frontendu
s bussiness logikou realizovanou backendem (včetně práce s DB)
typicky neudržují žádnou session (tj. ani DB session). Databázová spojení jsou
sdílená (pool) a do DB se připojují pod společným aplikačním uživatelem, který
není nijak svázán s uživatelem připojeným do aplikace.
Pesimistický přístup k zamykání záznamů používaný
v Oracle Forms je pro moderní webové technologie problematický a prakticky
se nepoužívá. Typicky se používá optimistické zamykání (update/delete
s where podmínkou na sloupec VERSION nebo s hodnotami všech sloupců nebo s
hash spočítaným z hodnoty všech sloupců). Případně se nedělá žádné
zamykání (tam kde to není potřeba).
Souběh takových DB transakcí s pesimistickým zamykáním
v Oracle Forms na stejných datech je problém. Aplikace, která pesimistické
zamykání nedělá a provede rovnou update/delete bude čekat na dokončení
transakce z Oracle Forms (až se uživatel vrátí z oběda a dá F10),
případně na vytikání nějakého timeoutu, kdy dojde k ukončení transakce a návratem
chyby.
Možná řešení (v pořadí dle náročnosti realizace od
nejjednoduššího):
- Nepotkávat se na stejných datech – tj. neměnit stejná data z aplikací používajících odlišné zamykací strategie.
- Dělat v nové aplikaci pesimistické zamknutí přes „SELECT FOR UPDATE” těsně před update/delete – tohle umí třeba JPA 2.0 přes LockModeType.PESSIMISTIC_WRITE.
- Upravit defaultní chování Oracle Forms aplikace na optimistické zamykání. Lze realizovat sloupečkem VERSION a DB triggerem na kontrolu správné verze a zvyšování čísla verze. Stejný sloupeček pak může používat i nová aplikace (jen nesmí zvyšovat číslo verze, v JPA lock mode OPTIMISTIC (bez FORCE INCREMENT)Tato úprava ale způsobí omezení uživatelského komfortu Oracle Forms aplikace.
Žádné komentáře:
Okomentovat