W dniu 2012-06-04 16:14, Maciej Sobczak pisze:
> On 4 Cze, 10:31, zażółcony<r...@c...pl> wrote:
>
>>> 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
>
> Jeśli to tak nazwiesz, to wszyscy wiedzą, o co chodzi, ale specjalnie
> tej nazwy nie użyłem, bo w odniesieniu do obsługi transakcji znaczenie
> tego skrótu ma się nijak. Ale faktycznie chodzi o to samo.

Skrót jest kiepski, ale pojęcie transakcji i pojęcie zasobu
już nie są tak odległe. Do transakcji i pliku jako 'bazę przykładów'
dałbym jeszcze 'mutex', lub inaczej semafor binarny.
W przypadku tego ostatniego sytuacja wydaje mi się najbardziej
jaskrawa: semafor opuszczasz PRZED try, a podnosisz w finally.
Każda inna konstrukcja to prośba o brak parzystości operacji na semaforze.

W przypadku transakcji bd masz:
begin = alokacja zasobu (abstrakcyjna rezerwacja zasobów bazy danych),
commmit = zapis zasobu + jego zwolnienie,
rollback = obsługa błędu + jego awaryjne zwolnienie.

Z powyższego masz wprost widoczne, dlaczego begin jest przed try
a commit i rollback 'w środku'.

>> (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.
>
> Destruktora. Nie ma problemu z garbage collectorem, może sobie być i
> jedno i drugie. To, że Javie jest tylko jedno to wybór projektantów
> języka a nie ograniczenia paradygmatyczne. GC nadaje się do obsługi
> pamięci ale nie od obsługi interakcji ze światem zewnętrznym.
Myśląnad tym - patrz 'closures'. Ale jest to problem w Javie
dobrze rozpracowany za pomocą innych wzorców, jeden właśnie taki,
o jakim mowa - try-catch-finally. Problem jest trochę, jak
obiekt wyskakuje 'na zewnątrz', kiedy pełny cykl jego życia
trudno objąć jedną funkcją. Wtedy jest trochę zabawy, ale generalnie
da się z tym całkiem dobrze żyć.

>
>>> 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.
>
> Fuj. Powinni tego zakazać.
Po przesiadce z c++ na Javę też nie mogłem się początkowo
w tym odnaleźć, ale po kilku latach kompletnie mi nie żal :)
Do destruktorów absolutnie nie tęsknię :)

>> Wyobraź sobie, że zamiast transakcji masz tam operację otwarcia pliku,
> [...]
>> 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ąć.
>
> Ja tego unikam używając języków, gdzie mogę mieć normalne RAII. Bo
> zastanawianie się, gdzie postawić begin względem try to odwracanie
> uwagi od głównego zagadnienia, typowe dla języków niskiego poziomu.

Imo nie jest to większe odwracanie uwagi, niż wtedy, gdy
np. z założenia pchasz wrażliwe operacje w konstruktory obiektów
i potem musisz się zastanawiać, czy obiekt, który utworzyłeś
na pewno się w pełni zainicjalizował, czy mu czegoś brakuje
i czy przypadkiem destruktor się nie wypierniczy. A wywaka w
konstruktorze to w przypadku niektórych języków jest sprawa
bardzo brzydka. Akurat walczę z tematem przy okazji konstruowania
obiektów OLE z poziomu języka FoxPro.
BTW. Automatyczny 'rollback' w destruktorze obiektu transakcji też
ćwiczyłem. Dopóki ktoś nie zapomni o commicie brzmi cukierkowo :)
Imo w tym wypadku zamiast konstrukcji typu TransactionScope
czy RAII podobnych lepiej korzystać z abstrakcji
oddzielających kwestie bazy danych od logiki biznesowej
(transakcyjność jako aspekt, zewnętrzny manager transakcji
automagicznie otaczający dostarczoną funkcję biznesową
transakcją - tak, jak to się robi obecnie w Javie i w C#
zdaje się również).