Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.java > #13142

Re: Parallelprogrammierung

From Patrick Roemer <sangamon@netcologne.de>
Newsgroups de.comp.lang.java
Subject Re: Parallelprogrammierung
Date 2017-10-03 20:15 +0200
Organization news.netcologne.de
Message-ID <or0k4t$djf$1@newsreader4.netcologne.de> (permalink)
References <f2naabFfb7jU1@mid.individual.net> <oq7qee$duf$1@gwaiyur.mb-net.net> <f3hiahFjtstU1@mid.individual.net>

Show all headers | View raw


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<String[]> 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

Back to de.comp.lang.java | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-09-23 16:44 +0200
  Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-09-24 10:30 +0200
    Re: Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-10-03 15:40 +0200
      Re: Parallelprogrammierung Patrick Roemer <sangamon@netcologne.de> - 2017-10-03 20:15 +0200
        Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-08 22:15 +0200
          Re: Parallelprogrammierung Patrick Roemer <sangamon@netcologne.de> - 2017-10-09 12:36 +0200
          Re: Parallelprogrammierung "Christian H. Kuhn" <qno-news@qno.de> - 2017-10-12 20:23 +0200
            Re: Parallelprogrammierung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-13 09:01 +0200

csiph-web