Vítejte v našem pokračování seriálu o nastavení kompatibility a „skrytých“ funkcích pro zvýšení výkonu. V prvním příspěvku jsme se zabývali příkazem QUERY BY FORMULA a jeho vlivem na chování aplikace. Druhý příspěvek se týkal možnosti kompatibility„Použít tečku a čárku jako zástupné znaky„, abyste se vyhnuli potížím typu „čísla se zobrazují jako >>>>>>>>>“ .
V tomto třetím díle se budeme zabývat vnořenými transakcemi.
Pokud tato volba není na stránce Kompatibilita viditelná (protože jste vytvořili strukturu pomocí 4D v11 nebo novější) nebo je již povolena, není třeba číst dále. Pokud tomu tak není, vaše aplikace běží v režimu emulujícím 4D v2004. Nejenže přicházíte o spoustu skvělých funkcí, ale jste také v riskantní pozici, protože tento režim již není v 4D testován.
Když 4D před 25 lety poprvé zavedlo transakce, podporovalo pouze jednu úroveň transakcí: operace byly buď v transakci, nebo ne. Již více než 10 let však 4D podporuje víceúrovňové (vnořené) transakce. Měli byste je využívat!
Pokud jste transakce nikdy nepoužívali, radím vám, abyste si přečetli tento příspěvek na blogu o transakcích… v opačném případě čtěte dál!
Příznak kompatibility vnořených transakcí
Proč tedy vůbec existuje tato možnost? Není lepší vždy používat vnořené transakce?
Ano, je to mnohem lepší. Váš stávající kód však mohl být napsán pouze s jednoúrovňovými transakcemi, proto tato možnost.
START TRANSACTION
START TRANSACTION // second call by accident, ignored from 4D v2004
VALIDATE TRANSACTION // v2004 was now at the end, no transaction running anymore
// v11 still has a transaction open…
Proč? Co by se mohlo stát? Jsem rád, že se ptáte!! Řekněme, že koncový uživatel ukončí aplikaci s pouze jednoúrovňovými transakcemi, která může mít stále otevřené nepotvrzené, neověřené transakce. Ty budou automaticky zrušeny a veškerá práce může být ztracena!
Před povolením příznaku kompatibility vnořených transakcí byste měli pečlivě zkontrolovat svůj kód a ujistit se, že všechna volání transakcí jsou vyvážená. Ověřte, zda jsou nejen otevřené, ale také uzavřené. Například metoda volaná uvnitř podmínky IF by mohla spustit transakci, ale mohla by být těžko k nalezení, pokud kód není dobře strukturovaný a uspořádaný.
Existují dva způsoby, jak to zkontrolovat:
- První je provést kompletní audit kódu, což by mohlo být časově velmi náročné. Existuje však ještě jedna možnost.
- Pokud vaše aplikace používá pouze jeden proces, mohlo by to být velmi jednoduché. V události On Exit zkontrolujte, zda jsou ještě otevřené nějaké transakce. Pokud ano, nahlaste to (pošlete si e-mail, zavolejte administrátorovi atd.) A ověřte transakci (za předpokladu, že se jednalo o náhodně otevřenou transakci).
Protože budete mít s největší pravděpodobností více procesů, budete je muset identifikovat. Pokud máte obecnou metodu, kterou voláte v každém procesu při jeho spuštění nebo ukončení, žádný problém. Pokud ne, budete muset tyto procesy najít a každý z nich upravit. Na konci každého procesu zkontrolujte Transaction level.
V tuto chvíli nedělejte nic jiného. Než začnete používat vnořené transakce, zkontrolujte svůj kód!
pozastavení transakcí
Jakmile povolíte vnořené transakce, všimnete si další výhody. Můžete stisknout tlačítko odložení!
Řekněme, že jste uvnitř transakce a potřebujete zvýšit počítadlo uložené v jiné tabulce(např. , číslo faktury). Dokud je transakce otevřená, jsou všechny změněné záznamy uzamčeny, takže je nemohou měnit jiní uživatelé nebo procesy. Zatímco pro samotnou fakturu to může být v pořádku, pro počítadlo čísla faktury to tak dobré není. V minulosti se vývojáři snažili tento problém obejít spuštěním dalšího procesu a vytvořením procesů, které by se staraly o komunikaci. To je spousta kódu jen proto, aby se něco spustilo mimo transakci. Naštěstí existuje lepší způsob… Jakmile jsou vnořené transakce povoleny, můžete je kdykoli pozastavit. To vám umožní inkrementovat čítač a pokračovat v transakci.
To je tak fantastická funkce, že je o ní v dokumentaci celý článek!
Paměť
Ať už vnořené transakce používáte, nebo ne, měli byste si být vědomi toho, že transakce zvyšují potřebnou paměť , protože upravená data se ukládají do dočasné vyrovnávací paměti. Nejen to, ale interně 4D také vytváří dočasné indexy, které umožňují spouštění dotazů.
Výsledkem je, že čím větší jsou vaše tabulky (protože se indexuje více polí a modifikuje více záznamů), tím více paměti je potřeba. Pokud je paměť nedostatečná, vedle souborů .4DD se vytvoří dočasné soubory (pro uložení dočasné vyrovnávací paměti). Tyto soubory sice řeší nedostatek paměti, ale mohou snížit výkon vaší aplikace.
Takže i když jsou transakce skvělé, není nejlepší nápad manipulovat s miliony záznamů uvnitř jedné!