IB 6.5 auf Win-NT, 20 user = 'DEADLOCK' Problem

[thomas absmann]

Hallo,
wir haben IB6.5 im Einsatz für Client/Server System mit 20 Useren und viel Datentraffic. Nun entsteht ab und zu der Fehler (Meldung aus dem IB-Server Logfile) "LOCK CONFLICT ON NO WAIT TRANSAKTION DEADLOCK".
Die Transaktionseinstellungen vom Server sind: write, consistency, read_committed und wait.
Vom IB-Client: snappschuß, concurency und nowait.
Ich glaube nun daß diese Einstellungen nicht korrekt sind und dadurch kann es zu oben beschriebenen Fehler kommen. Kann mir jemand sagen wie diese Transaktionseinstellungen besser sind um Deadlocks zu vermeden?
vielen Dank
Thomas

[Andreas Horlaender]

Hallo Thomas,<br>
ich kann nur Andreas Kosch's Buch InterBase empfehlen, dort ist auch eine sehr ausführliche Beschreibung der Transaktionsmechanismen und Sperrverfahren.
<p></p>
Gruß Andrea

[thomas absmann]

Hallo Andreas,
danke für den Tipp ich werde mir das Buch besorgen. In der zwischenzeit hab ich mal genauer bei dem Buch Client/Server von Andreas Kosch nachgelesen und da versteh ich zwei Dinge nicht.
1. Die definiton DEADLOCK beschreibt, daß zwei (oder mehrere) Benutzer gegenseitig auf die Bestätigung (Commit/rollback) warten. Nun gibt es aber die Transaktionsnummer die ja laut Definition nicht dieselbe sein kann, somit währe eine Abarbeitung dieser Transaktion lt. Transaktionsnummernreihenfolge möglich.
2. Es tritt ab und zu noch ein Fehler auf mit der exception zu wenig Arbeitsspeicher. Dabei werden in einer Transaktion viele SQL befehle (TQUERY)abgesetzt. Die Transaktion schreibt auf die Tabelle A und der Fehler tritt in der Transaktion auf beim lesen auf die Tabelle B. Für Tabelle B wird keine eigene Transaktion gestartet da es ja nur ums lesen in dieser geht. Der InterBase-TIL im Server lautet: WRITE, CONSITENCY, READ_COMMITED und WAITE. Wait deshalb weil ich umbedingt an dieser stelle schreiben muß. Die Clients die auf die Datenbank zugreifen haben die TIL: SCHNAPPSCHUSS (concurrency und nowait). Kann mir einer eine geeignetere TIL sagen. Ich tendiere beim Server auf SNAPSHOT statt Read_Commited