Hallo alle...

kann mir jemand bitte die Zusammenhänge erklären wie man den Datenbankzugriff, Transaktionen und mehrere Threads miteinander verknüpfelt ?
Szenario 1:
- Thread hat seine eigene Connection
- Thread hat seine Query´s
- Thread hat seine eigene Transaktionen (wenn benötigt)

...sollte ohne Probleme funktionieren.

Szenario 2:
- eine Connection
- gemeinsame Transaktion
- alle Threads sollen die gemeinsame Connection, die aktuelle Transaktion benutzen

geht das überhaupt ? Wenn ja was muß wo hin ?

Scenario 3:
- eine SP die weiterführenden Änderungen übernimmt (Erklärung siehe Hintergrund)
Wartet die Hauptanwendung auf das Beenden der SP oder geht´s sofort weiter nach Abschicken des Aufrufes.

Hintergrund:
Ich habe ein kleines DB Framework gebastelt. Normalerweise sind wenig Daten wegzuschreiben. Das merkt man kaum (auch ohne Threads). In sehr wenig Fällen sind bei Änderung eines Datensatzes in Tabelle1 auch Änderungen in Tabelle2 notwendig. Die Anzahl der zu änderten DS sind ansteigend hoch. Das wollte ich gern auslagern.

Danke für Info´s

Das Erste sollte wohl ohne Probleme gehen.

Ansonsten bieten einige Datenbankkomponenten sowas wie ThreadPooling, welches man aktivieren müßte,
um dort vermutlich mit mehreren Threads auf einer Connection zu arbeiten.
In wie weit das immer sicher funktioniert und ob es mit einer Transaktion threadübergreifend arbeitet ... k.A.

...gerade gefunden...

Zitat:

Zitat von http://www.devart.com/ibdac/faq.html:
Yes, IBDAC is thread-safe but there is a restriction. The same TIBCConnection object cannot be used in several threads. So if you have a multithreaded application, you should have a TIBCConnection object for each thread that uses IBDAC.

... damit fällt Szenario 2 raus... Gott sei Dank... An die Umbauarbeit wollte ich nicht denken.

dann bleibt nur Szenario 3 und die Frage der Ausführung. Wenn die SP über einen Trigger des "Masterdatensatzes" angeworfen wird sollte doch nach dem Ändern des einen Datensatzes die Anwendung weitermachen. Oder wartet die auch auf die SP ?

ad Szenario 3: Ein SP-Aufruf ist synchron, d.h. der aufrufende Thread ist so lange blockiert, bis die SP abgearbeitet wurde.

Danke an alle...

Gut. Dann gebe ich dem Thread die DB Info´s mit und er macht eine extra Connection auf... (Szenario 1).

Ist immer wieder schön mit Euch zu diskutieren...

Moin... gleiches Thema nächste Zwickmühle.

Hintergrund:
- Tabelle 1, Feld "Bezeichnungen" wird geändert
- Tabelle 2, Feld "Bezeichnung" muß angepaßt werden (kann lange dauern)
- Tabelle 3, Feld "Bezeichnung" muß angepaßt werden (kann lange dauern)

Ablauf: (stark vereinfacht)
1. SaveObjects
1.1 Update Tabelle 1 -> Execute
1.2 Thread für Update Tabelle 2 und 3 (eigene Connection/Transaktion)
2. LoadLists
-> Problem: Datenkonsistenz ist nicht gewährleistet. Wenn in Tabelle 2 oder 3 was schiefläuft ist Tabelle 1 geschrieben da nicht in der selben Transaktion
-> Lösung ?: notfalls im Thread den Datensatz in Tabelle 1 wieder auf den ursprünglichen Wert setzen...

mögliche Lösung:
- alle Updates in den Thread
-> Problem: unter Umständen sind die Daten aller 3 Tabellen noch nicht Committed und das LoadLists holt noch die alten Daten

welche Lösung wäre akzeptabel ?

Danke...

Zitat von haentschman:

Dann gebe ich dem Thread die DB Info´s mit und er macht eine extra Connection auf... (Szenario 1).

Gestalte das ganze doch noch etwas abstrakter: Warum bittest du nicht einen "DB-Manager" um eine Query und arbeitest dann mit dieser?! Beim Start der Anwendung musst du dem DB-Manager lediglich einmal die Connection-Informationen übergeben und gut ist das. Hast du Verbindungen zu mehreren DBs, so kannst du auch sowas machen DbManager.GetQuery('oracle'); und DbManager.GetQuery('access'); .

In dieser GetQuery()-Methode wird dann automatisch geprüft, welcher Thread aufgerufen wird. Ist für den Thread noch keine Verbindung aktiv, so wird eine neue aufgebaut und die Query in diesem Kontext erzeugt.

Zudem würde ich das ganze dann auch noch mit Interfaces verknüpfen, was dazu führt, dass du dich weniger um die Speicherverwaltung kümmern musst. Ebenso abstrahierst du dann auch von der genutzten Datenbank und bietest deinem Programm eine einheitliche Schnittstelle für den DB-Zugriff an.

Leider ist das ganze bisher nur in meinem Kopf und noch nicht ganz umgesetzt Bin aber auf dem besten Weg gerade...

Zitat von haentschman:

welche Lösung wäre akzeptabel ?

Du weißt doch von vorn herein, was genau du updaten musst, oder? Dann packe das ganze doch in einen einzigen Thread und Transaktion und gut ist. Wie lange können solche Updates denn eigentlich dauern?! oO