Lock conflict obwohl die andere Transaction nicht mehr activ ist

[MyRealName]

Hallo,
ich habe ein seltsames Verhaltem welches ich im Moment nicht verstehe, vielleicht hat ja einer von Euch 'ne Idee..
Ich nutze Unidac ohne Autocommit in der UniConnection, mache also explizites Transaction handling.
Nun will ich für ein paar Stellen von einer Arbeitsqueue auf ein direktes sofortiges Bearbeiten umstellen.

Kurze Erklärung hierzu : Wenn ich eine Rechnung mache, muss ich nachsehen, ob die physischen Einheiten auch im Inventar vorhanen sind. Dazu gibt es eine Tabelle mit dem aktuellen Stand pro Location (Tabelle heisst ITEMDET) die von der Bewgungstabelle (ITEMACT) über einen trigger geupdated wird. Machen ich 2 Rechungen und vllt noch einen Wareneingang über das gleiche produkt in derselben Location, dann führt das zu lock conflicts machmal. Deswegen habe ich eine Arbeits queue, wo diedokumente speichern und anstelle die Bewegungen selbst zu schreiben, senden sie es an die Queue, die es dann zentralisiert macht und dann immer nur 1 Dokument durchlässt, so kommt es nie zum lock conflict. Allerdings kann es manchmal ein paar Sekunden dauern, bis das Dokument bearbeitet wurde und da kommt es dann zu Löchern wo die Produkte noch verfügbar sind obwohl schon verkauft.

Dazu will ich dann bestimmte Abgänge (Verkäufe und Verschiebungen von einer zur anderen Location) direkt mit einer Wait transaction machen, während Eingänge und zeit-unkritische dokumente weiterhin über die Queue laufen.

Nun das Problem (mit UniDAC) :

ich mache ein update auf ein Register in itemdet und lasse die transaktion "1" offen, dann hält meine wait transaction "2" auch schön an und wartet. Mache ich Commit auf Transaktion "1", dann kommt die "2" mit dem lock conflict zurück. Nicht was ich erwartet habe, dachte eigenetlich, dass sie jetzt ihre daten schreibt, aber gut, ist halt so. Ich mache also ein RollbackRetaining (weil rollback mir alle offenen Queries und Tabllen auf dem Formular schliesst) und dann starte ich das schreiben neu, kriege aber immer noch den lock conflict. In MON$TRANSACTIONS gibt es die Transaction aber schon garnicht mehr..

Ideen ? was mache ich falsch, wo habe ich einen Denk Fehler ?

EDIT: habe gerade probiert mein absolutes Ergebnis (UPDATE ItemDet SET ONHAND=:Qty WHERE Id=:ID) durch ein Delta-update zu ersetzen (UPDATE ItemDet SET ONHAND=Onhand + :Delta_Qty WHERE Id=:ID ). Damit er nach dem lock conflict dann den neuen Wert nutzen kann. Aber das hat auch nicht geholfen :(

[hstreicher]

das Problem dürfte das RollbackRetaining sein
da der Transaction erhalten bleibt


Von Devart:
procedure RollbackRetaining;
Call the RollbackRetaining method to roll back all changes of data associated with the default database transaction to the database server and then retain the transaction context.

mfg Hannes

[MyRealName]

Das ist auch mein Gedanke.

ich habe es mal auf eine Transaktion umgebaut, die extra nur für das Schreiben in diesem Abschnitt da ist. Das heisst ich mache erst ein explizites StartTransaction und in einem try...Except Block Commit oder Rollback, also nichts Retaining.

Aber jetzt habe das folgende Problem :

Obwohl ich ein explizites Rollback und ein neues StartTransaction mache, scheint die Datenbank die Indices schon geupdated zu haben und behauptet felsenfest, dass das Document mit dieser Id schon existiert und ich den index oder den primary key verletze. Mache ich aber in eine console ein select auf die Tabellen dann ist da nichts.

Ist das ein bug von firebird ? oder UniDAC ? Kennt das jemand ?

[MyRealName]

OK, Fehler gefunden, beim Frameworkumbau einen default Wert gelöscht und der wurde dann doch noch benutzt und der hat mir das Query zur falschen Transaction zugewiesen.

Mit Rollback und Commit geht alles.