Občas jsem zde ukázal nějakou vychytávku z pl/sql a nazval jsem to “rychlotipem”, krátký post, který si myslím že občas dokázal ukázat nějakou zajímavou funkci apod. Postupem času to lehce upadlo, neb mi přišly daleko zajímavější novinky (nejprve 11.2g pak 12.1c), kterým jsem udělal i vlastní kategorii. A protože jsem se rozhodl jít lehce více do šířky a začít k PL/SQL psát i něco o APEXU (a nebude to nejspíše jediné přidané topic - Informatica by mohla být další ;)). Tedy nová kategorie, kam budu cpát tipy a triky na APEX – paralelně se seriálem o workoutlogu. Takže rychlotip číslo# 1 – jak nastavit delší přežití session, aby nás neotravovalo neustálé odlogovávání při vývoji (případně jde použít stránku bez nutnosti logování – public a je to hned).
Ještě trošku odbočka, dneska jsem narazil na hezký citát, který řiká proč je dobré si věci zkoušet a nejen o nich číst:
“když člověk čte, zapamatujete si v průměru 10–20 % obsahu, když člověk poslouchá přednášku, zapamatuje si jen 20–30 %, když člověk něco aktivně dělá, zapamatuje si až 60–70 %”
Autorem citátu je Robert Kiyosaki, autor investičního bestselleru “Bohatý táta, chudý táta”. Osobně jsem to nedočetl, to se fakt nedalo. Řiká se, že ani špatné knihy do koše nepatří, ale.. Podle mého názoru to neni kvalitní literatura. Raději Jitku Veslou z VŠE, George Sorose, André Kostolanyho. Nicméně hezký citát, škoda že nám nikdy ve škole podobná čísla neřekl (speciálně nám, co studovali dálkově).
Tolik dnešní citát a nyní k APEXu. V APEXu je možnost nastavení maximální délky session na dvou úrovních:
-
Na úrovni instance – nastavuje instance adminstrátor. Toto nastavení dědí aplikace, které mají nastavení délky session null (default a nikoliv 0).
-
Na úrovni jednotlivé aplikace – nastavuje workspace administrátor. Buď aplikace zdědí hodnotu z instance, když není vyplněno (null) nebo má vlastní (nějaké číslo) či má nekonečnou délku (0) – viz dále.
Takže jak to nastavit :
-
Na úrovni instance loginem administrátora /apex/apex_admin. V Manage Instance -> Security -> Session Timeout. Je tam parametr Maximum Session Length in Seconds (default 28800 = dva dny) a Maximum Session Idle Time In Seconds (dafault 3600 = hodina). Ohledně nejvyšší možné povolené hodnoty je nutné si všimnou poznámky v nápovědě: “This session duration may be superseded by the operation of the job that runs every hour which deletes sessions older than 12 hours.”. Viz dále.
-
Na úrovni aplikace loginem workspace administrátora /apex/apex. V Home -> Editace vybrané aplikace -> Edit Application Properties -> záložka Security -> sekce Session Timeout. A zde jsou možné 4 nastavení:
- Maximum Session Length in Seconds - maximální délka session v sekundách, null – dědí z instance level, 0 – nekonečno, číslo – sekundy.
- On Session timeout direct to this URL – Název mluví za vše. Přesměrování když vyprší uvedený čas. Nejspíše někam na stránku s loginem s chybovou hláškou apod. Stránka by měla být public, páč uživatel nebude přihlášen v tu chvíli.
- Maximum Session Idle Time Second – maximální délka session v sekundách při nečinnosti, null – dědí s instance level, 0 – nekonečno, číslo – sekundy
- On session idle time timeout direct to this URL – Název mluví za vše. Přesměrování když vyprší uvedený čas při nečinnosti. Nejspíše někam na stránku s loginem s chybovou hláškou apod. Stránka by měla být public, páč uživatel nebude přihlášen v tu chvíli.
Co je nepříjemné je hláška o tom, že i když nastaví programátor více, může ho stejně killnout job:
” The session duration may be superseded by the operation of the job that runs every eight hours which deletes sessions older than 12 hours.”
Což znamená, že na domácím prostředí by bylo fajn ošéfovat i tenhle job. Což se dá udělat třeba pod SYSem a pohledem do all_scheduler_jobs:
Nápověda v APEXu doslova řiká: “job který běží každých 8 hodin a killuje session starších 12 hodin”. Nevím, ale podle ALL_SCHEDULER_JOBS je job ORACLE_APEX_PURGE_SESSIONS nastaven na start každou hodinu a to také dělá dle ALL_SCHEDULER_JOB_RUN_DETAILS. Každopádně je třeba s ním něco udělat. Job volá WWV_FLOW_CACHE.PURGE_SESSIONS, která má nějakou takovouhle signaturu:
procedure purge_sessions (
--
-- Purge flow session state tables to avoid keeping session
-- state no longer needed. Purge all sessions older then a certain
-- age. May result in a very large number of delete transactions.
-- Commit is performed between delete commands.
--
p_purge_sess_older_then_hrs in number default 12,
p_security_group_id in number default null,
p_report_results in varchar2 default 'NO');
Job volá purge_sessons bez parametrů a dědí defaultní hodnoty, tedy p_purge_sess_older_then_hrs=12. Takže co s tím? Řešení je spousta od DISABLE jobu, přes DROP až po změnu spouštění. Nejlepší bude co nejméně invazivní akce, takže jen změna textu jobu a místo volaní procedury bez parametrů – s defaultními, tak se svými hezčejšími:
Nejprve asi PL/SQL Block – líp se do toho bude hrabat a případně přidávat:
begin
DBMS_SCHEDULER.SET_ATTRIBUTE (
name =>'APEX_040200.ORACLE_APEX_PURGE_SESSIONS',
attribute =>'JOB_TYPE',
value =>'PLSQL_BLOCK');
end;
Pak z toho tedy pl/sql block (nejen volání procky) a naše parametry – hodil jsem tam 48 hodin.
begin
DBMS_SCHEDULER.SET_ATTRIBUTE (
name =>'APEX_040200.ORACLE_APEX_PURGE_SESSIONS',
attribute =>'JOB_ACTION',
value =>'begin
WWV_FLOW_CACHE.PURGE_SESSIONS(48,null,''N'');
end;');
end;
A Oracle job nezdokumentoval, takže vložení komentáře, že to bylo upraveno.
begin
DBMS_SCHEDULER.SET_ATTRIBUTE (
name =>'APEX_040200.ORACLE_APEX_PURGE_SESSIONS',
attribute =>'COMMENTS',
value =>'Sprostě zeditováno');
end;
Ještě je třebas počkat si na jedno proběhnutí jobu, že je to všechno v pořádku a doběhne se stavem SUCCESS. Tolik k prodloužení života sessions.
