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!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Wed, 07 May 2014 13:29:24 +0200 Organization: A noiseless patient Spider Message-ID: 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> <60hajlhql29h$.1jh2ixlq35vtm.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 7 May 2014 11:29:24 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="23dab0694e4174fdc880833ec67fa650"; logging-data="15989"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/oX9w9GNIPZyTy/RxmQJOa" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <60hajlhql29h$.1jh2ixlq35vtm.dlg@40tude.net> Cancel-Lock: sha1:Tdn4ap8xchHnvLxq8scJ2aGO5w0= X-Enigmail-Version: 1.6 Xref: news.eternal-september.org comp.lang.ada:19731 Date: 2014-05-07T13:29:24+02:00 List-Id: Le 07/05/2014 11:09, Dmitry A. Kazakov a écrit : >> 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. Well, if in addition Begin/End of transactions are from Initialize/Finalize of a controlled objet, you are safe. >>> >> 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. Which SQLite is not, unfortunately, and despite what they seem to tell. In our case, we have less than 1% chance of having two transactions at the same time, so the bottleneck is not an issue (as long as we don't ruin the database, which IS important). Other contexts may be different, of course. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr