Path: csiph.com!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-89-0-205-101.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: Re: Parallelprogrammierung Date: Tue, 3 Oct 2017 20:15:57 +0200 Organization: news.netcologne.de Distribution: world Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 3 Oct 2017 18:15:57 +0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-89-0-205-101.netcologne.de:89.0.205.101"; logging-data="13935"; mail-complaints-to="abuse@netcologne.de" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 In-Reply-To: Content-Language: en-US Xref: csiph.com de.comp.lang.java:13142 Responding to Christian H. Kuhn: >> Bibliotheken sollten niemals Exceptions in Standardsituationen werfen. >> Dafür sind sie zu teuer. Und daran halten sich die Standard >> Lock-Implementierungen auch. > > Wenn List exportData(String, String) den Lock nicht bekommt, > gibt es null zurück. Wer fremde Bibliotheken aufruft und nicht auf null > checkt, hat es nicht besser verdient ;-) Für ein Lock ist es eine Standardsituation, wenn ein acquire nicht auf Anhieb erfolgreich ist. Für den Benutzer ist es eine Ausnahmesituation, wenn der Batch-Export nicht durchgeht. > Und nachdem das geklärt ist, ist mir aufgefallen, dass auch andere > Rechner ihre (eingeschränkten) QDatabase-Objekte mit ihren spezifischen > Clients auf die Datenbank zugreifen und nicht über den Prozess, in dem > mein QDatabase-Objekt die Locks verwaltet. Ich darf also noch Locks auf > die Tabellen in Postgresql setzen. Andere Gruppe. Wenn die DB das Transaktionshandling übernimmt, greift das auch für konkurrente lokale Clients und Du kannst das Lock-Zeugs getrost wieder zappen. Viele Grüße, Patrick