Race Condition: Report-Abfrage blockiert Buchung

[od-peter]

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.

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.

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;

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.

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? :)

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.

Hi Peter,

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

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

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.

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.

In f3c5ef3b1eb1ca09d3821538500af85f3b1ffcd2/erp:

Row level lock statt table level lock verwenden.

Betrifft #2368.

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