Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.java > #13145
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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