On Jun 3, 11:30 pm, "AK" <n...@n...com> wrote:

> Np: jezeli w catch jest rollback (a zakladam ze tak wlasnie jest),
> a zawiedzie begin w try to moze zostac wycofana poprzednia
> z zagniezdzonych transakcji.

Ale begin może się wyłożyć w zasadzie tylko dlatego, że nastąpił
problem z utrzymaniem sesji (ktoś urwał kabel?). Wtedy wszystkie
niezamknięte transakcje i tak szlag trafi i to po stronie serwera,
więc klienckie rollback nic już nie zmieni. To oczywiście zależy od
tego, czym są te transakcje, jak realizowane, być może w ogóle nie ma
wymagania na ciągłość połączenia (HTTP?), itp.
Ten kod może być zarówno dobry jak i niedobry, zależnie od kontekstu.

Ja najchętniej korzystam z traksakcji z automatycznym rollbackiem,
wyzwalanym przez destruktor. Wtedy opcja B jest kompletnie bez sensu
(zły scope), natomiast obiekt zarządzający transakcją i tak nie zrobi
żadnego rollbacka jeśli begin się nie powiodło, co powoduje, że opcja
B jest jeszcze bardziej bez sensu a opcja A nie dość, że jest
poprawna, to nawet da się zwykle zapisać prościej.
Rozważania nt. A/B to rozwiązywanie problemów, których w ogóle nie
powinno być ale niestety są, bo język programowania jest dziadowski.
No właśnie - co to za język programowania?

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com