Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-87-79-185-117.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: Re: Parallelprogrammierung Date: Mon, 9 Oct 2017 12:36:27 +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: Mon, 9 Oct 2017 10:36:27 +0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-87-79-185-117.netcologne.de:87.79.185.117"; logging-data="13514"; 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:13144 Responding to Marcel Mueller: > On 03.10.17 20.15, Patrick Roemer wrote: >> Responding to Christian H. Kuhn: >>> 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. > > Da musst Du aber höllisch aufpassen. Vom Distributed Deadlock bis zur > Snapshot too old Exception ist da so ziemlich alles möglich. Da helfen ihm die VM-lokalen Locking-Konstrukte, die er bisher auf dem Client eingebaut hat, auch nicht. Viele Grüße, Patrick