Witam,

trochę już programowaniem się zajmuję, ale ostatnio trafiła do mnie
sugestia z obszaru, którego bym się nie spodziewał.

A mianowicie, ktoś zasugerował, żeby zamiast konstrukcji A, używać B ale
już nie zaargumentował dlaczego (chodzi o komunikację z bazą danych).

A:
<code>
try {
BeginTransaction();
...
CommitTransaction()
} catch { ... }
</code>

B:
<code>
BeginTransaction();

try {
...
CommitTransaction()
} catch { ... }
</code>

Na chłopski rozum, sugestia wydaje mi się błędna, bo co gdy przy
tworzeniu transakcji się wysypie?

--
Mateusz Bogusz

do góry

W dniu 2012-06-03 15:17, Karol Y pisze:
> <code>
> BeginTransaction();
>
> try {
> ...
> CommitTransaction()
> } catch {
RollbackTransaction(); <-- zapewne o to chodzi
}
> </code>
>
> Na chłopski rozum, sugestia wydaje mi się błędna, bo co gdy przy
> tworzeniu transakcji się wysypie?
>

do góry

Dnia Sun, 03 Jun 2012 15:17:05 +0200, Karol Y napisal:

> Witam,
>
> trochę już programowaniem się zajmuję, ale ostatnio trafiła do mnie
> sugestia z obszaru, którego bym się nie spodziewał.
>
> A mianowicie, ktoś zasugerował, żeby zamiast konstrukcji A, używać B ale
> już nie zaargumentował dlaczego (chodzi o komunikację z bazą danych).

Pomijając odpowiedź już w wątku: ktoś nie zaargumentował dlaczego,
a tutaj dodatkowo wyciąłeś kod, który jest istotny. Taka
zabawa w głuchy telefon prowadzi do niezrozumienia.

>
> A:
> <code>
> try {
> BeginTransaction();
> ... CommitTransaction()
> } catch { ... }
> </code>
>
> B:
> <code>
> BeginTransaction();
>
> try {
> ... CommitTransaction()
> } catch { ... }
> </code>
>
> Na chłopski rozum, sugestia wydaje mi się błędna, bo co gdy przy
> tworzeniu transakcji się wysypie?

1. Sprawdź, czy może się wysypać BeginTransaction()
2. Sprawdź, czy jeżeli się wysypie, to treść catch/finally będzie
poprawna.
3. Sprawdź, czy jeżeli się wysypie BeginTransaction() jest cokolwiek
do wyczyszczenia w catch/finally.

Edek

do góry

Użytkownik "Karol Y" <k...@o...pl> napisał:

> A:
> <code>
> try {
> BeginTransaction();
> ...
> CommitTransaction()
> } catch { ... }
> </code>
>
> B:
> <code>
> BeginTransaction();
>
> try {
> ...
> CommitTransaction()
> } catch { ... }
> </code>
>
> Na chłopski rozum, sugestia wydaje mi się błędna

Mowiac ogolnie:
Sugestia B jest jak najbardziej celna i to nie tylko na chlopski rozum.
PS: Za wersje A powinno sie surowo karac.

AK

do góry

On 2012-06-03, AK <n...@n...com> wrote:
> Użytkownik "Karol Y" <k...@o...pl> napisał:
>
>> A:
>> <code>
>> try {
>> BeginTransaction();
>> ...
>> CommitTransaction()
>> } catch { ... }
>> </code>
>>
>> B:
>> <code>
>> BeginTransaction();
>>
>> try {
>> ...
>> CommitTransaction()
>> } catch { ... }
>> </code>
>>
>> Na chłopski rozum, sugestia wydaje mi się błędna
>
> Mowiac ogolnie:
> Sugestia B jest jak najbardziej celna i to nie tylko na chlopski rozum.
> PS: Za wersje A powinno sie surowo karac.

A jakieś argumenty merytoryczne? Bo na chłopski rozum to właśnie
pierwsza część ma sens.

--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> napisał:

> A jakieś argumenty merytoryczne? Bo na chłopski rozum to właśnie
> pierwsza część ma sens.

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.

AK

do góry

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

do góry

W dniu 2012-06-04 09:34, Maciej Sobczak pisze:

> Ja najchętniej korzystam z traksakcji z automatycznym rollbackiem,
> wyzwalanym przez destruktor. Wtedy opcja B jest kompletnie bez sensu

Czyli korzystasz ze wzorca projektowego RAII
(nazwa niezbyt trafna, ale tak już zostało).
Taką konstrukcję zastosujesz tylko w językach bez asynchronicznie
działającego garbage collectora, tzn. w takich, w których masz jasno
zdefiniowany moment odpalania konstruktora. W języku takim jak
Java czy C# nie robi się tego z pomocą destruktorów, tylko
ew. możesz walnąć (w C#) klauzulę 'using'.
(patrz
http://en.wikipedia.org/wiki/Resource_Acquisition_Is
_Initialization#Resource_management_without_RAII
).

Sugestia wyrzucenia begina przed try jest oczywiście niedoskonała,
ale jak najbardziej poprawna. W podanej w przykładzie konstrukcji
sekcja catch służy zasadniczo do obsługi rollbacka transakcji,
a nie wszelkich problemów zwiazanych z bazą danych. Jeśli chcemy
obsłużyć jakiś gruby problem z bazą, powodujacy, że nawet begin nie
wskakuje, to nic nie stoi na przeszkodzie by całość otoczyć
jeszcze jednym try-catchem, takim do obsługi błędów 'grubych'.

> (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?
Jeden z języków, w którym nie masz możliwości zastosowania wzorca RAII.

Wyobraź sobie, że zamiast transakcji masz tam operację otwarcia pliku,
zapisu do tego pliku i zamknięcia pliku. Przed try próbujesz
plik otworzyć do zapisu. Jeśli się to nie powiedzie, błąd 'gruby', wypad
z funkcji.
Dopiero, kiedy się powiedzie wchodzisz do try/catch/finally - i tu
np. zadaniem sekcji 'finally' jest posprzątanie deskryptora otwartego
pliku (close itp). Masz ściśle określone, wąskie zadanie związane
ze zwalnianiem jakiegoś zajętego zasobu. Jeśli zasób (plik, transakcja)
w ogóle nie został zajęty, to nie ma w ogóle sensu wchodzenie do
'finally', czy 'catcha' (catch ma za zadanie obsługę błędów
odczytu/zapisu do otwartego zasobu, a nie 'wszelkich możliwych').
Zauważ, że jeśli wrzucisz otwieranie po try, to potem w finally musisz
się zastanawiać, czy robić close, czy nie (dodatkowy if). A tego właśnie
chcemy uniknąć.

do góry

Użytkownik "Maciej Sobczak" <s...@g...com> napisał:

> Ten kod może być zarówno dobry jak i niedobry, zależnie od kontekstu.

Ten kod (A) jest zawsze zly.
Tak jak zawsze zly jest kod typu:

FILE* f;

try
{
f = fopen(...);
....
flose(f);
{
catch ( ... ):
{
...
flose(f);
...
}

czy typu:

Object* obj;

try
{
obj = new Object();
....
delete obj;
}
catch ( ... ):
{
...
delete obj;
...
}

AK

do góry

On 2012-06-04, AK <n...@n...com> wrote:
> Użytkownik "Maciej Sobczak" <s...@g...com> napisał:
>
>> Ten kod może być zarówno dobry jak i niedobry, zależnie od kontekstu.
>
> Ten kod (A) jest zawsze zly.
> Tak jak zawsze zly jest kod typu:
[...]
> flose(f);
[...]
> delete obj;

Zakładasz niesłusznie, że bezwzględnie wywołane fclose() i bezwzględnie
wywołane delete są równoważne operacji rollback.

--
Secunia non olet.
Stanislaw Klekot

do góry