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


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

Re: Parallelprogrammierung

From "Christian H. Kuhn" <qno-news@qno.de>
Newsgroups de.comp.lang.java
Subject Re: Parallelprogrammierung
Date 2017-10-12 20:23 +0200
Message-ID <f49q9sF98slU1@mid.individual.net> (permalink)
References <f2naabFfb7jU1@mid.individual.net> <oq7qee$duf$1@gwaiyur.mb-net.net> <f3hiahFjtstU1@mid.individual.net> <or0k4t$djf$1@newsreader4.netcologne.de> <ore110$jo4$1@gwaiyur.mb-net.net>

Show all headers | View raw


Am 08.10.2017 um 22:15 schrieb Marcel Mueller:
> Da musst Du aber höllisch aufpassen. Vom Distributed Deadlock bis zur
> Snapshot too old Exception ist da so ziemlich alles möglich.

Im Allgemeinen hast du sicher recht. Im konkreten Fall gibt es genau
einen Prozess, der Daten ändern darf, und das tut er einmal am Tag. Dazu
gibt es n Clients, die die Daten lesen. Eventuell auch Clients, die ich
nicht kenne. Das dürfen alle gleichzeitig, außer es wird gerade
geschrieben, dann darf niemand lesen. Wenn ich da einen Deadlock haben
will, muss ich schon ziemlich gut (schlecht?) sein.

> Wirklich sicher wäre man nur im DB-Isolationslevel "Serializable", was
> erstens bei weitem nicht jede Datenbank kann

Postgresql. Kann. LOCK ... IN ACCESS EXCLUSIVE MODE

> und zweitens dem
> DB-Administrator auf die Palme bringt, weil es den Durchsatz auf 386-er
> Niveau begrenzt.

Bei dieser Anwendung: Wayne. cronjob startet täglich morgens, wird bis
mittags fertig, der typische Anwender schläft zu der Zeit ;-) Es ist
nicht auszuschließen, dass das Schreiben der Daten auch einmal pro Woche
reicht.

> Es gibt also durchaus gute Gründe sich mit eigenen Sperrkonzepten bei
> verteilten Anwendungen zu befassen.

Ja. Hier sollte es allerdings mit explicit locking in der DB reichen.

lg
QNo

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