JDBC mit mehreren Threads.

[java_chris]

Hallo,

ich habe das folgende Problem:
Mit mehren Threads greife ich auf eine Datenbank über JDBC zu. Alle Threads, öffnen eine eigene Datenbankverbindung und arbeiten mit und ohne auto_commit sowie read_only true oder false.
Jetzt scheint es, dass die einzelnen Threads sich gegenseitig blockieren „deadlocks“ obwohl sie teileweise auf verschieden Tabellen sowie immer mit verschiedenen Schlüsseln arbeiten.

Hat jemand eine Idee zu diesem Problem????

 

[RicoSoft]

meine erste frage: könnten zu viele connections zum server aufgebaut werden?

ich würde da mit einem pool arbeiten, das ist wahrscheinlich die bessere lösung für das problem, aber so ohne eine zeile code ist es schwierig, das problem zu lokalisieren

 

[java_chris]

die maximale anzahl der verfügbaren connects wird nicht erreicht.

code..hmm ist sehr lang...müßte ich zusammen streichen.

Läuft ein Thread alleine gibt es keine Probleme. Nach meine Meinung bringt synchronized auch nichts, da die Thrreads auf unterschielde Daten zugreifen.

Was meinst Du als pool. einen eigenständigen thread der alleine die datenbank zugriffe durchführt ?

 

[abollm]

[..]
Was meinst Du als pool. einen eigenständigen thread der alleine die datenbank zugriffe durchführt ?

Er meint vermutlich "connection pooling".

Connection pooling ist so eine Art Caching von Datenbankverbindungen, die im JDBC 2.0 extension API enthalten ist. Das erlaubt dir die Wiederverwendung von DB-Verbindungen und reduziert damit den üblichen Overhead in deinen DB-Applikationen, d.h. es minimiert den Aufwand zum Aufbau und zum Schließen einer oder mehrerer DB-Sessions.

 

[java_chris]

wenn ich "connection pooling" einsetzen würde, müßte ich die ganze application umschreiben. das problem scheint ja wohl nur aufzutreten, wenn eine veränderung auf der db durchgeführt wird.

gibt es auch eine möglichkeit ohne "connection pooling" auszukommen?

 

[java_chris]

Jetzt erst einmal eine prinzipielle Frage:

Ist JDBC überhaupt Threadsicher ?????

 

[abollm]

Jetzt erst einmal eine prinzipielle Frage:

Ist JDBC überhaupt Threadsicher ?????

Zunächst zu der obigen Frage:

Ja, JDBC ist threadsicher.

Zu deiner darüber gestellten Frage hinsichtlich der Möglichkeit, ohne "Connection Pooling" auszukommen, würde ich ebenfalls sagen: Ja!

Meine Bemerkung war vor allem als Erklärung auf die obige Antwort von RicoSoft bezogen.

Jetzt aber einige grundsätzliche Dinge zu deinem Problem:

Setzt du ein so genanntes Mutex-Verfahren um deine jeweiligen DB-Aufrufe herum ein, d.h. eine Art Ausschluss mit denen du verhinderst, dass nebenläufige Prozesse _gleichzeitig_ auf deine Daten zugreifen und so unter Umständen inkonsistente Zustände herbeiführen (Deadlock)? Du _musst_ die Prozesse synchronisieren. Du darfst keinen weiteren JDBC-Aufruf starten, solange der andere noch in Bearbeitung ist. Es sei denn, beide haben ihre eigene DB-Verbindung.

Oder anders ausgedrückt: Zwei Threads können sich nicht _gleichzeitig_ einen DB-Connect teilen. Du musst die Zugriffe synchronisieren (single threading).

----------------------------------------------------------------------------

Somit scheint dein Problem ein Synchronisationsproblem zu sein.

BTW: Welche DB nutzt du?

 

[Bleiglanz]

BTW: Welche DB nutzt du?

WICHTIGE Frage! Manche DBs können nur "Tabellenweise" sperren, und wenn du ohne autocommit arbeitest, dann kann das schon problematisch werden

Frage: sind in deinem Code überhaupt irgendwo synchronized Blöcke? Vielleicht ist es ja ein Java-Deadlock und hat gar nix mit der Datenbank zu tun?

 

[java_chris]

Hallo,

ich habe das Problem gelößt. Ich hatte bei den lesenden SQL-Statements auto commit eingestellt, dass aber bei der INGRES DB wohl nicht funktioniert. Habe die commit's nun selber gesetzt und es gibt keine Probleme mehr.

Vielen Dank für Eure Anregungen.

java_chris