Threadingproblem

[deitysou]

Hallo,<br>

aus dem Titel lässt sich wohl erschließen, wo das Problem liegt...
ich arbeite in meinem Programm mit Threads.
<br>
Mein System setzt sich eigentlich aus zwei wesentlichen Merkmalen zusammen, die dieses Konzept rechtfertigen (?).
<br>
a) Es gibt Module zur Bearbeitung von Kundendatensätzen. (Überraschung *g*)
b) Ein User muß manchmal über bestimmte Ereigisse unterrichtet werden.
Dazu gehören Events wie:
- Ein gesperrter Datensatz, wird wieder freigegeben.
- Nachrichten empfangen.
- etc.
<br>
welche über Threads gesteuert werden.
<br>
Wie zu erwarten war, kommt es dann natürlich zu Problemen.
Ich verwende nämlich ein Connection-Objekt über das alle Anfragen an die Datenbank laufen.
Und siehe da.. ich krieg (oh Überraschung) die Meldung "Datenbankverbindung ist derzeit mit einem anderen Befehl beschhäftigt." (oder so).
<br>
Um dem Ganzen entgegen zu wirken habe ich natürlich CriticalSections eingebaut und was man so alles für Threads benutzen sollte.
<br>
Das Resultat ist gut, ich kriege diese Fehlermeldung nicht mehr.
Allerdings denke ich, dass der Schein trügt..
Da Module mit ADO-Objekten (Command, DataSet) jederzeit Daten abfragen können, befürchte ich, dass in seltenen Fällen es doch zu Fehlern kommt.
<br>
Deshalb meine eigentliche Frage:
- Gibt es eine saubere und zuverlässige Möglichkeit zu prüfen ob
die Connection frei ist und ggf. diese für einen kurzen Moment
für andere zu sperren?
- Ich hatte auch über ein zusätzliches Connection-Objekt
nachgedacht, befürchte aber, dass ich dann in Teufels Küche
kommen, wenn es um CALs geht.
<br>
Thx für ein paar Tips.
<br>
//Edit: TADOConnection.State für die Statusabfrage hab ich schon gefunden, funktioniert die zuverlässig?

[Andreas Kosch]

Hallo,
der saubere Weg beim Zugriff über die ADO-Objekte (bzw. über die <i>dbGo</i>-Wrapperkomponenten von Delphi für die nativen ADO-Objekte) besteht darin, <b>zusätzliche</b> ADO-Verbindungen für die Threads zu nutzen. Da es sich um COM-Objekte handelt, gelten automatisch die Regeln des aktivierten COM-Apartments. Da ein Adminstrator das von ADO genutzte Apartment global (Maschinenweit) ändern kann, ist jede Abweichung vom "normalen Weg" gefährlich ;-)
<br>
Auch bei ADO greift der automatische Datenbankverbindungs-Pool für den SQL Server auf der Client-Seite (OLE DB), so dass es keine Performanz-Nachteile hat, wenn die Threads ständig <i>Connection</i>-Instanzen öffen und schließen.
<br>
&gt;..habe ich natürlich CriticalSections eingebaut ..
Derartige Exclusiv-Sperren verringern aber auch den Nutzen von zusätzlichen Threads, denn in diesem Fall wird ja immer nur ein Thread zur gleichen Zeit ausgeführt. Wenn die Ausführung einer SQL-Anweisung in einer CriticalSection läuft, wird der zusätzliche Thread eigentlich sinnlos.
<br>
&gt;...wenn es um CALs geht...
Solange alle Threads im gleichen Prozess laufen, erhöht sich der Verbrauch aus lizenzrechtlicher Sicht nicht. Denn auch die ADO-Objekte spalten in bestimmten Situationen hinter den Kulissen <b>automatisch</b> zusätzliche <i>Connection</i>-Instanzen ab, so dass im gleichen Prozess mehrere Datenbankverbindungen gleichzeitig offen sind. Über die <i>Leistungs</i>-Anzeige von Windows kann man dies visuell kenntlich machen

[deitysou]

Hallo,
genau die Information hab ich gebraucht.
Das ADO-Objekte hinter den Kulissen manchmal diese Verbindungen aufbauen hab ich von dir schonmal in einem anderen Thread gelesen, allerdings war ich mir nicht sicher und wollte nochmal nachfragen ob das für diese Lizenzen ok ist.
<br>
Somit danke ich um ein weiteres. ;