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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.datemas.de!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Wed, 7 May 2014 11:09:02 +0200 Organization: cbb software GmbH Message-ID: <60hajlhql29h$.1jh2ixlq35vtm.dlg@40tude.net> References: <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com> <5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net> <5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net> <1fe3nmaxcrah3.1t38gw7e4zfz3$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.dca.giganews.com comp.lang.ada:186282 Date: 2014-05-07T11:09:02+02:00 List-Id: On Wed, 07 May 2014 10:26:41 +0200, J-P. Rosen wrote: > Le 07/05/2014 09:30, Dmitry A. Kazakov a écrit : >>> The only constraint on the user is to call Begin_Transaction at the >>> > beginning, and End_Transaction in the end, which is quite acceptable for >>> > database transactions! >> I tend to have a controlled transaction handler, which rolls back upon >> finalization [unless there was explicit Commit]. > Sure, I said it was a simplified view. In practice, Begin/End > transactions are part of a limited_controlled object declared in the > callback procedure of AWS. > >> P.S. It would be nice to have a mandated way to detect if Finalize was >> called with an exception being propagated. E.g. the pending transaction is >> committed in Finalize when there is no exception and rolled back otherwise >> There is a way to do this, but it is GNAT-specific. > Since everything is handled by the task, it is easy to have a local > flag, and when you close the transaction do a rollback unless the > previous order was commit. This how I do it too. The point is to do this safer, without a need to commit explicitly, which could be easily forgotten or misplaced (done before last requests). When you leave the scope, the changes are committed. If you leave the scope by a DB request or other error (manifested as an exception), it is rolled back. >> P.P.S. Monitor is not always safer, not even always possible, because some >> clients require a transaction bound to the single task. I.e. you could not >> start several transactions in the monitor on behalf of several tasks. > I don't understand your remark here. It is precisely because SQLite did > not seem to be able to handle transactions from several tasks > (concurrent or not) that I delegated all the DB interface to a single > task. This serializes all requests, but it is no big deal in our case, > since a transaction is never longer than the time to build a web page. Yes, but for a DBMS capable of handling multiple transactions, it would become a bottleneck. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de