Forum Delphi.cz

Databáze => Firebird a Interbase => Téma založeno: Stanislav Hruška 22-10-2020, 09:32:11

Název: Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 22-10-2020, 09:32:11
Základ je od „Čítaj hlavne tu“
Je to voľné pokračovanie témy: Table.Delete OK, Table.Post NIE
Analyzoval som svoj prípad a tu je výsledok aj s otázkami.
Hlavný problém je v skutočnosti, že mám na formulároch TFDTAble. A to pre:
Celá nalýza vychádza z Jirkovho príkladu, kde vytvára a ničí jednotlivé transakcie. Chcem sa priblížiť k tomuto riešeniu. Všekty Querys už mám k dispozícii.
Plánujem funkciu FbTransaction(Auto, ReadOnly: Boolean; Isolation: TFDIsolation default xiReadcommited(?)): TFDTransaction(?).Isolation je pre prípady práce nad viacerými SVB naraz – hlavne tlačové zostavy, štatistiky apoc.. Nie zmena údajov.
Čítaj hlavne tu
Pracovná tabuľka. Asi bude najvhodnejšie použiť transakcie z dátoveho modulu.
Hlavná otázka je: vytvárať zakaždým UpdateTransaction? Z analýzy mi vychádza, že to nie je dobrý nápad. Mala byť trvalá.
Je to dlhé, snáď to prečítate.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: pf1957 22-10-2020, 12:43:10
Moc jsem to necet a navic jsme pouzivali vlastni Datasource, DB awared komponenty a zadnou table:

1. kazdy podruzny thread "ze zakona" vlastni spojeni, vsechny transakce existuji jen na nezbytne nutnou a jsou manualni, vsechno kolem transakci psano puristicky
2. V UI tj. hlavni treadu jedna trvale otevrena read commited read only transakce sdilena vsemi UI widgety
3. Pro zapis dat do DB jako u threadu.

Pod carou:
Mit soucasne vice aktivnich transakci na jedno spojeni u Interbase/FireBirdu lze, ale u jinych DB ne a pak s tim specielne FireDac caruji a dovoli existenci nekolika transakci, ale ve skutecnosti je nejak spoji do jedine a pak se to chova dost nepredvidatelne napr. je mozna menit data jen v RO transakci a kolegu z toho dost bolela hlava, nez prisel na to, ze ty lety odzkousene transakce nefunguji. Takze pokud je na obzoru sance, ze se to bude nekdy portovat na jiny RDBMS, tak bych tento zpusob s trvale otevrenou txn nedoporucoval.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 22-10-2020, 13:18:51
Ďakujem.
Mne stále vŕta v hlave ten Insert/Edit, ktoré vyžadujú "trvale" otvorenú transakciu. Tým mám na mysli dlhý čas jej otvorenia: kým užívateľ zadá údaje a rozhodne sa ich Uložiť - Table.Post(Commit)/Zrušiť - Table.Cancel(nič).
Predpokladám že pri Commit/Rollback je najlepšie použiť práve túto transakciu.
Je nejaká možnosť mať pre Table.UpdateTransaction, ktorá nebude trvalo otvorená? AutoStart nič nerieši.
.
Nepredpokladám viac otvorených transakcií typu Update. Na to si dávam pozor. Pri OnlyRead to je jedno.
.
Keď som nepoužíval DB komponenty, tam to problém nebol. Transakciu som aktivoval v okamihu volania Uložiť -> Insert/Edit -> Table.Post.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Jirka 22-10-2020, 21:26:22
Citace: pf1957 l
1. kazdy podruzny thread "ze zakona" vlastni spojeni, vsechny transakce existuji jen na nezbytne nutnou a jsou manualni, vsechno kolem transakci psano puristicky
2. V UI tj. hlavni treadu jedna trvale otevrena read commited read only transakce sdilena vsemi UI widgety
3. Pro zapis dat do DB jako u threadu.
AMEN

Citace: Stanislav Hruška
Keď som nepoužíval DB komponenty, tam to problém nebol.
A proč jsi je přestal používat - když ti to fungovalo ?
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 22-10-2020, 23:12:42
Citace
A proč jsi je přestal používat - když ti to fungovalo ?
Bežalo mi to aj s DB komponentami a už aj teraz. Takže to je v poriadku :)
Momentálne mi vyhadzuje memory leak a ja neviem zistiť kde! Výpis je taký o ničom. EurekaLog. Len zobrazím hlavný formulár a zavriem ho. Zobrazenie ďalšieho formulára mi počet ML nezvýšil.
Prikladám výpis, keby mal niekto chuť sa na to zbežne pozrieť.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Jirka 23-10-2020, 10:10:14
Momentálne mi vyhadzuje memory leak a ja neviem zistiť kde! Výpis je taký o ničom. EurekaLog. Len zobrazím hlavný formulár a zavriem ho.
FDFunction.pas                 
NewQry               
řádek 80   ?

Uvolňuješ v té funkci  vše co jsi tam  vytvořil ?
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 23-10-2020, 10:26:34
Práve teraz som zistil, že v jednom prípade nie. Hľadalo sa to veľmi zle. Lenže pred aplikovaním dynamicky vytváraním transakcií tú chybu nehádzalo :o Prečo?
Už ich mám len 5. Ale hlášky sú už rozumnejšie.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Jirka 23-10-2020, 10:55:49
Lenže pred aplikovaním dynamicky vytváraním transakcií tú chybu nehádzalo :o Prečo?
Většinou když něco vytvářím měl bych to i uvolňovat ..

Jinak (pokud maš spravné hodnoty)  vše nejlepší k životnímu jubileu.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 23-10-2020, 11:40:53
Áno, údaje mám pravdivé ;) Ďakujem. Mám to na výročie oslobodenia 8. 5.
Ak zabudnem uvoľniť TQuery, tak dostanem charakteristické oznamy. V tomto prípade boli oznamy pre mňa nečitateľné. Okrem prvého.
Bolo to zapríčinené tým, že sa jedná o prihlasovací formulár vytváraný a ničený v dpr. Ale nie ako formulár aplikácie. TQuery som naozaj neničil.
Keď som Query uvoľňoval vo FormDestroy, tak som dostal AV. Vyriešil CloseQuery. Neviem prečo sa FormDestroy spúšťa 2 x. To nebolo príčinou AV.
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Jirka 23-10-2020, 11:50:19
Bolo to zapríčinené tým, že sa jedná o prihlasovací formulár vytváraný a ničený v dpr. Ale nie ako formulár aplikácie.
Tady je ideální  příležitost jak bezezbytku  použít kompletně ten zaslaný příklad
tj na login formu nemít žádné datové komponenty ..
samozřejmě musíš mít předem vytvořený datamodul s Connection
Název: Re:Životnosť transakcií – v mojom kontrétnom prípade
Přispěvatel: Stanislav Hruška 23-10-2020, 12:25:01
Bolo to zapríčinené tým, že sa jedná o prihlasovací formulár vytváraný a ničený v dpr. Ale nie ako formulár aplikácie.
Tady je ideální  příležitost jak bezezbytku  použít kompletně ten zaslaný příklad
tj na login formu nemít žádné datové komponenty ..
samozřejmě musíš mít předem vytvořený datamodul s Connection
To všetko mám splnené. Mám 2 x TAdvEdit