Erstellt vor 18 Monaten

Geschlossen vor 14 Monaten

#2368 closed Fehler (fixed)

Race Condition: Report-Abfrage blockiert Buchung

Erstellt von: od-peter Verantwortlicher:
Priorität: normal Meilenstein:
Komponente: kivitendo ERP Version: 3.0.0 unstable
Schweregrad: normal Stichworte:
Beobachter:

Beschreibung

Zusammenhängend mit #2367 haben wir festgestellt, dass bestimmte zeitaufwändige Reporte (z.B. Lieferplan, UStVA, etc.) während der Ausführungszeit Buchungsvorgänge blockieren.
Ob andere Vorgänge (und falls ja, welche) von dieser Race Condition betroffen sind werden ich noch prüfen und ggf. ergänzen.

Auf jeden Fall ist dadurch die Multiuser/Multitask?-Fähigkeit von kivitendo leider stark eingeschränkt.

Anhänge (1)

transnumber_for_update.diff (2.0 KB) - hinzugefügt von bibi@… vor 18 Monaten.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (12)

comment:1 Antwort: Geändert vor 18 Monaten durch s.schoeling@…

Das ganze programm ist nicht wirklich auf Multiuserfähigkeit getestet. Es ist zwar mit dem groben Gedanken gebaut, aber nie daraufhin auch getestet worden.

Das mit dem blockieren liegt wahrscheinlich am TansNumber? Generator, da wollten wir eh noch was machen.

Und zu guter letzt, wieviel ist bei Dir länger? Normal sollte kein Request länger als eine Sekunde dauern.

comment:2 Antwort: Geändert vor 18 Monaten durch bibi@…

Hallo Peter,

siehe auch #2349.

Versuch mal bitte folgendes SQL-Statment während der Blockade und schaue, ob für Tabelle defaults ein Lock nicht gegeben wird / werden kann.

SELECT t.relname, l.locktype, page, virtualtransaction, pid, mode, granted FROM pg_locks l, pg_stat_all_tables t WHERE l.relation=t.relid ORDER BY relation ASC;

comment:3 als Antwort auf: ↑ 1 Geändert vor 18 Monaten durch od-peter

Replying to s.schoeling@…:

Und zu guter letzt, wieviel ist bei Dir länger? Normal sollte kein Request länger als eine Sekunde dauern.

Naja, so lange, wie der parallel laufende Report eben benötigt.
Im Falle von #2367 (Lieferplan) bis zu 2 Minuten.
Ein UStVa-Report kann auch schon mal bis zu einer Minute dauern...
...und dieser Zeit sind keine Buchungen möglich.

comment:4 als Antwort auf: ↑ 2 ; Antwort: Geändert vor 18 Monaten durch od-peter

Replying to bibi@…:

Versuch mal bitte folgendes SQL-Statment während der Blockade und schaue, ob für Tabelle defaults ein Lock nicht gegeben wird / werden kann.

jep, sieht ganz danach aus:

relname locktype page virtualtransaction pid mode granted
pg_class relation \N 11/98922 25057 AccessShareLock? t
pg_index relation \N 11/98922 25057 AccessShareLock? t
pg_namespace relation \N 11/98922 25057 AccessShareLock? t
acc_trans relation \N 9/477201 25039 AccessShareLock? t
ap relation \N 9/477201 25039 AccessShareLock? t
ar relation \N 9/477201 25039 AccessShareLock? t
buchungsgruppen relation \N 10/15625 25046 AccessShareLock? t
chart relation \N 10/15625 25046 AccessShareLock? t
chart relation \N 9/477201 25039 AccessShareLock? t
custom_variable_configs relation \N 10/15625 25046 AccessShareLock? t
defaults relation \N 7/96623 25038 AccessShareLock? t
defaults relation \N 10/15625 25046 AccessShareLock? t
defaults relation \N 10/15625 25046 AccessExclusiveLock? f
gl relation \N 9/477201 25039 AccessShareLock? t
language relation \N 10/15625 25046 AccessShareLock? t
parts relation \N 10/15625 25046 AccessShareLock? t
payment_terms relation \N 10/15625 25046 AccessShareLock? t
printers relation \N 10/15625 25046 AccessShareLock? t
tax relation \N 10/15625 25046 AccessShareLock? t
taxkeys relation \N 9/477201 25039 AccessShareLock? t
taxkeys relation \N 10/15625 25046 AccessShareLock? t
units relation \N 10/15625 25046 AccessShareLock? t
units_language relation \N 10/15625 25046 AccessShareLock? t

und nun? :)

comment:5 als Antwort auf: ↑ 4 Geändert vor 18 Monaten durch bibi@…

Replying to od-peter:

jep, sieht ganz danach aus:

defaults relation \N 7/96623 25038 AccessShareLock? t
defaults relation \N 10/15625 25046 AccessShareLock? t
defaults relation \N 10/15625 25046 AccessExclusiveLock? f

und nun? :)

Nun? Das war nur, um zu prüfen, dass es nicht doch an noch was anderem liegt. In TransNumber? wird eben ein exklusiver Lock auf defaults gemacht. Und wie Sven schon schrieb, soll da was geändert werden. Falls da die Tests positiv sind, könnte das auch eine Lösung für Dein Problem sein.

comment:6 Geändert vor 18 Monaten durch bibi@…

Hi Peter,

Du kannst evtl. mal den Patch probieren, den ich gleich hier anhänge.

Geändert vor 18 Monaten durch bibi@…

comment:7 Geändert vor 18 Monaten durch od-peter

Hi Bernd,

yep, das sieht viel besser aus!
Mit Deinem Patch klappt das Buchen definitiv zeitnah :)
Ob dabei irgendwas Anderes zu Bruch geht konnte ich nicht feststellen.

Gruß Peter

comment:8 Geändert vor 18 Monaten durch bibi@…

Hi Peter,

gut. Dann sollten wir definitiv weiter testen, ob nicht was anderes kaputt geht und ob die anderen Fälle dadurch auch entschärft werden.

Der Patch ist übrigens nicht wirklich von mir, sondern eigentlich von Mosu.

comment:9 Geändert vor 18 Monaten durch m.bunkus@…

Den Patch so, wie er ist, bitte nicht committen, da habe ich zwei Stilpunkte zu bemängeln:

  1. Keine auskommentierten Zeilen stehen lassen. Das verwirrt Leser des Sources nur. Wenn raus, dann richtig.
  2. Die Anordnung der trailing if in den ... FOR UPDATE-Änderungen bitte wieder fixen (alle drei if auf gleicher Höhe). Ja, das war zwischendurch schon einmal kaputt gegangen. Kein Grund, das noch weiter so zu belassen.

comment:10 Geändert vor 17 Monaten durch bibi@…

In f3c5ef3b1eb1ca09d3821538500af85f3b1ffcd2/erp:

Row level lock statt table level lock verwenden.

Betrifft #2368.

comment:11 Geändert vor 14 Monaten durch grichardson@…

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

keine Beschwerden seitdem, deshalb schließe ich den Bug jetzt.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.