Databáze > Firebird a Interbase

Životnosť transakcií – v mojom kontrétnom prípade

(1/3) > >>

Stanislav Hruška:
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.

pf1957:
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.

Stanislav Hruška:
Ď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.

Jirka:

--- 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.

--- Konce citace ---
AMEN


--- Citace: Stanislav Hruška ---Keď som nepoužíval DB komponenty, tam to problém nebol.

--- Konce citace ---
A proč jsi je přestal používat - když ti to fungovalo ?

Stanislav Hruška:

--- Citace ---A proč jsi je přestal používat - když ti to fungovalo ?
--- Konce citace ---

* 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ť.

Navigace

[0] Seznam témat

[#] Další strana

Přejít na plnou verzi