Mehrere DB-Verbindungen aus Dienst überfordern Firebird ?!

[DataCool]

Hi Leute,

ich habe 2 Firebird Datenbanken die ich aus einem Dienst herraus aus seperaten Threads anspreche.
Ein Thread importiert Daten aus einer anderen Datei und schreibt diese in "DB 2",
dabei werden Event gesteuert auch bei jedem "Insert, Update u. Delete" Daten in DB 1 geschrieben.
einer Anderer liesst Daten aus der "DB 1" und syncronisiert diese übers Inet mit einem Server.
Der Dienst hat die Berechtigung zur Interaktion mit dem Desktop und verbindet sich via BDE zur Datenbank.
Jeder Thread hat seine eigene DB-Verbindung, welche Dynamisch erzeugt und freigegeben wird !

Jetzt gibt es noch das GUI-Interface mit dem die Kunden auf der Datenbank(DB 1) arbeiten,
manchmal kommt es jetzt vor das die Kunden keine Änderungen an den Datensätzen mehr vornehmen können.
So wie's scheint bekommt die Query keine ErrorMessage nur die Daten bleiben unverändert.
Konnte das ganze bei mir noch nicht reproduzieren, aber Kunden die dieses Problem haben konnten mir keine Fehlermeldung nennen.

Ein Neustart des Rechners bringt wie so oft Abhilfe.

Hat irgentjemand eine Ahnung warum die Datenbank in eine Art "Locked" Zustand übergeht und der Dienst dabei scheinbar noch schreiben kann ?! Kann es an den Threads liegen ? An den mehrfachen DB Verbindungen die teilweise auf gleichen Tables Daten ändern ?
Oder ist das Problem bei der BDE zu suchen ? Den Diwnst könnte ich auf direkten Zugriff umstellen; das GUI-Interface nicht ohne weiteres.

Bin für jeden Tipp dankbar,

Greetz Data

[hoika]

Hallo,

1. BDE ist AFAIK nicht threadfest
was ist pro Thread an DB-Komponenten definiert ?
2. mind. auf FB 1.5 umsteigen.




Heiko

[mkinzler]

Besser noch FB 2.5, da kann man von er einen DB Abfragen auch die andere absetzen

[DataCool]

Hi Leute,

wenn das Umstellen mal eben so erledigt wäre, hätte ich das schon lange erledigt

Das ganze läuft in über 100 Standorten ...

Die Threads haben jeweils ein TDatabase und mehere TQuerys.

Greetz Data

[mkinzler]

Um so wichtiger ist es eine Alternative zur BDE zu implementieren.Die Migration von FB 1.x auf FB 2.x geht meist schmerzfrei.

[DataCool]

@mkinzler:

Stimme ich Dir absolut voll zu, das steht auch ganz oben auf meine ToDo-Liste für V2 meines Programms.

Allerdings brauche im Moment eine Quick & Dirty Lösung des Problems,
d.h. würde es helfen das ganze aus den Threads auszulagern und innerhalb eines Timers im Dienst auszuführen ?

Greetz Data

[hoika]

Hallo,

die Threads brauchen auch je ein TSession.
Such mal im Netz nach BDE multithread.

Heiko

[DataCool]

@Hoika:
^^^^ Gesagt getan,

werde jetzt in meine Klasse die die Datenbankverbindung kapselt für jede(s) Verbindung/TDatabase eine eigene Session erzeugen.
Wenn ich das richtig verstanden hae sollte das mein Problem bis zur Umstellung erstmal beheben, richtig ?

Greetz Data

[neo4a]

Ja, das hilft möglicherweise.

Deine Darstellung aus dem Eröffungs-Post deutet für mich auf ein Transaktions- Deathlock- Problem hin (zwei Verbindungen ändern Datensätze gleichzeitig). Das kann durchaus durch After/Before/Trigger ausgelöst sein und damit Änderungen auch in dritten Tabellen verursachen (bspw. Log- oder Summary-Tabellen). Dies wäre dann allerdings ein DB-Design- Problem, das Du auch nicht mit Sessions löst.

Prüfe, ob Trigger oder Stored Procedures involviert sind, die bei Datenänderung ihrerseits Daten ändern. Falls das nicht der Fall ist, dann war's tatsächlich nur die BDE mit unklarem Transaktionsverhalten.

--
Andreas

[hoika]

Hallo,

Einspruch
Unklares Transaktons-Verhalten der BDE ?
Damit hatte ich noch nie Probleme.

Aber trotzdem noch eine Frage zu Transaktionen.
Steuerst du die Transaktionen selber (DB.StartTransaction / DB.Commit),
oder überlässt du das der BDE ?


Heiko