From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Handling transactions?
Date: Tue, 28 Jul 2015 15:23:46 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mp8ock$5hv$1@loke.gir.dk>
References: <d075fc4c-083d-4654-b04a-15f84c8511c9@googlegroups.com>
 <mp5e9k$ba2$1@dont-email.me>
 <6b5c318e-430d-4950-9762-e0ecdaa0ac9a@googlegroups.com>
 <lya8uhzm7n.fsf@pushface.org>
 <9976ca19-a558-4f4e-80d3-a9b37ee07326@googlegroups.com>
 <40c8dba8-85e9-42e7-8316-96c976531ab4@googlegroups.com>
 <mp6h92$q5h$1@loke.gir.dk> <xrh840crgak6$.og5ru41qaz0o$.dlg@40tude.net>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1438115028 5695 24.196.82.226 (28 Jul 2015 20:23:48 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 28 Jul 2015 20:23:48 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:27097
Date: 2015-07-28T15:23:46-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:xrh840crgak6$.og5ru41qaz0o$.dlg@40tude.net...
> On Mon, 27 Jul 2015 19:10:09 -0500, Randy Brukardt wrote:
>
>> This is typically used in a block:
>>
>>     declare
>>          My_Lock : Lock; -- Gets lock.
>>     begin
>>          -- Do operations needing the lock.
>>     end; -- The lock is freed here, no matter how this block is 
>> completed.
>>
>> I suspect that you could use a similar pattern for transactions (although
>> I've never tried it).
>
> Yes, the way I did it was similar:
>
>   declare
>      My_Transaction : Transaction (...);
>   begin
>      -- Do operations
>      Commit (My_Transaction);
>   end;
>
> The transaction object has the flag Committed set by Commit. Upon an
> exception the flag remains not set and Finalize rolls back. Without an
> exception the flag is set and Finalize commits.

Looks good to me.

> The problem with this approach is that you cannot propagate exceptions on
> errors from Finalize when commit or rollback fails.

Well, you can if your only intent is to kill the program (Finalize will 
cause Program_Error to be raised -- somewhere -- if it propagates an 
exception). If you want to do recovery of some sort, it would be a problem. 
(Off-hand, I'm not sure what recovery one can do when rollback fails, and 
the recovery from a commit failure seems to be to rollback, so it seems that 
killing the program is the primary goal. But of course YMMV.)

                           Randy.