Autor Téma: Životnosť transakcií – v mojom kontrétnom prípade  (Přečteno 676 krát)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
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:
  • tabuľku s ktorou pracujem. Transaction (Auto, ReadOnly, ReadCommited) a UpdateTransaction (ReadCommited).
  • tabuľky pre DB TMS komponenty typu Lookup. Musia mať pre Lookup DataSource. Transacction (Auto, ReadOnly, ReadCommited).
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.
  • Prípady, kde obchádzam tabuľky. Hneď na začiatku vytvorím transakciu/ie a priradím ku TQuery. Do ostatných Querys budem dávať odkaz na transakciu z týchto TQuery. Pri uzatvorení alebo zničení Query zároveň zničím transakcie. Čisté, bez problému
  • Pracujem s tabuľkami
  • a. Lookup – v rámci (pod)formulára vytvorím jednu transakciu a priradím. Jej životnosť je počas celej životnosti formulára. Toto ešte nemám vyriešené, ale viem to urobiť (parameter, globálna premenná).
  • b. Pracovná tabuľka. Tu mám problém
Čítaj hlavne tu
Pracovná tabuľka. Asi bude najvhodnejšie použiť transakcie z dátoveho modulu.
  • Transaction (Auto, ReadOnly, ReadCommited). Životnosť počas životnosti formulára. Keďže je auto, tak predpokladám, že sa aktivuje len v prípade potreby
  • UpdateTransaction (ReadCommited) – tá by mala mať životnosť len ak ju potrebujem. Alebo sa na to vykašľať?
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á.
  • Insert, Edit: musia mať transakciu. Tu je problém. Užívateľ ide na pivo. Jedine, žeby som to po určitom čase zrušil. Zadávanie údajov nie je tak zložité, žeby som si to nemohol dovoliť
  • Cancel:musí použiť transakciu z Insert, Edit
  • Post: musí(?) použiť transakciu z Insert, Edit. Ak mám Querys, ktoré menia niekde údaje, tak isto musia použiť danú transakciu
  • Locate(): tu môžem zakaždým vytvoriť a hneď zničiť Transaction (Auto, ReadOnly, ReadCommited).
Je to dlhé, snáď to prečítate.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3290
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #1 kdy: 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.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #2 kdy: 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.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline Jirka

  • Hrdina
  • ****
  • Příspěvků: 435
  • Karma: 9
    • Verze Delphi: XE2
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #3 kdy: 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 ?

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #4 kdy: 22-10-2020, 23:12:42 »
Citace
A proč jsi je přestal používat - když ti to fungovalo ?
  • Pôvodný dôvod si už tak veľmi nepamätám. Možno si to tu pre zaujímavosť pohľadám
  • TMS DB komponenty mi uľahčili prácu a zbavil som sa kopy kódu
  • Vytváram si zoznam DB "komponentov". Tam zapisujem nejaké vlastnosti. Robil som to ručne. To bola práca pre otroka. Pri použití Table to je automatické. Ďalšia kopa kódu preč
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ť.
« Poslední změna: 22-10-2020, 23:16:38 od Stanislav Hruška »
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline Jirka

  • Hrdina
  • ****
  • Příspěvků: 435
  • Karma: 9
    • Verze Delphi: XE2
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #5 kdy: 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 ?

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #6 kdy: 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.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline Jirka

  • Hrdina
  • ****
  • Příspěvků: 435
  • Karma: 9
    • Verze Delphi: XE2
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #7 kdy: 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.

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #8 kdy: 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.
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.

Offline Jirka

  • Hrdina
  • ****
  • Příspěvků: 435
  • Karma: 9
    • Verze Delphi: XE2
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #9 kdy: 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

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 6004
  • Karma: 44
    • Verze Delphi: W10 + D11
Re:Životnosť transakcií – v mojom kontrétnom prípade
« Odpověď #10 kdy: 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
W10 64b, Delphi 10.4, FireBird 3.05
Expert na kladenie nejasne formulovaných otázok.