takidoso
Erfahrenes Mitglied
Hallo und Halli,
Ich habe folgende Situation, die ich möglichst ohne böse Fallen erledigen können will:
Ich habe eine Art Dispatcher-Anwendung, die vorrangig mit Dateien umgeht, die sie aus vorgegebenen Verzeichnissen via polling holt und dann je nach Dateinamen eine entsprechende z.B. Konverteranwendung anstößt. Dabei geht dieser Dispatcher ist multithreaded (er benutzt hier Thread-Pool Funktionalität).
Nun gibt es folgende Anforderung:
ein Konverterprogramm liest bestimmte Informationen aus einer Datei und speichert sie zwischen.
Ein zweiter Konverter bekommt gegebenenfalls Dateien, die Referenzen beinhalten, mit denen er in der Persistenzschicht die vom 1. Konverter zuvor gesicherten Daten ausliest und für die Konvertierung verwendet.
Als Persistenzschicht hatte ich mir Derby als embeded DB angedacht mittels JDBC.
Nun meine Frage sowohl Konverter1 als auch Konverter2 sind in verschiedenen Threads. Kann ich hier den selben User für die Derby-DB verwenden, oder käme da unter Umständen durcheinander (in Teufels Küche)?
In den Derby-Dokumenten habe ich gelesen dass die vor stoppen der JVM DB geschlossen werden sollte, um nicht sinnlos eine Recovery beim nächsten Start zu provozieren. Außerdem wäre vielleicht ein Connection-Pooling nicht schlecht. Hat jemand mit Derby als embeded DB und Multithreading Erfahrungen gesammelt oder einen guten Link für best Practice?
Für Connection-Pooling und einem ordnungsgemäßen schließen der DB müsste irgendwie der Dispatcher nach meinem Verständnis zuständig sein. Ich dachte da an Apache Connection-Pool und las da was über JNDI. Mal eine vielleicht blöde Frage ist JNDI zwingend nötig um das Connection-Pooling zu nutzen, ich wollte mir vielleicht Lernzeit sparen, denn die How_tos im commons_dbcp erscheinen mir als dort blutigen Anfänger etwas unverständlich und damit abschreckend.
mit super dankbaren Grüßen für gute Hinweise.
Takidoso
Ich habe folgende Situation, die ich möglichst ohne böse Fallen erledigen können will:
Ich habe eine Art Dispatcher-Anwendung, die vorrangig mit Dateien umgeht, die sie aus vorgegebenen Verzeichnissen via polling holt und dann je nach Dateinamen eine entsprechende z.B. Konverteranwendung anstößt. Dabei geht dieser Dispatcher ist multithreaded (er benutzt hier Thread-Pool Funktionalität).
Nun gibt es folgende Anforderung:
ein Konverterprogramm liest bestimmte Informationen aus einer Datei und speichert sie zwischen.
Ein zweiter Konverter bekommt gegebenenfalls Dateien, die Referenzen beinhalten, mit denen er in der Persistenzschicht die vom 1. Konverter zuvor gesicherten Daten ausliest und für die Konvertierung verwendet.
Als Persistenzschicht hatte ich mir Derby als embeded DB angedacht mittels JDBC.
Nun meine Frage sowohl Konverter1 als auch Konverter2 sind in verschiedenen Threads. Kann ich hier den selben User für die Derby-DB verwenden, oder käme da unter Umständen durcheinander (in Teufels Küche)?
In den Derby-Dokumenten habe ich gelesen dass die vor stoppen der JVM DB geschlossen werden sollte, um nicht sinnlos eine Recovery beim nächsten Start zu provozieren. Außerdem wäre vielleicht ein Connection-Pooling nicht schlecht. Hat jemand mit Derby als embeded DB und Multithreading Erfahrungen gesammelt oder einen guten Link für best Practice?
Für Connection-Pooling und einem ordnungsgemäßen schließen der DB müsste irgendwie der Dispatcher nach meinem Verständnis zuständig sein. Ich dachte da an Apache Connection-Pool und las da was über JNDI. Mal eine vielleicht blöde Frage ist JNDI zwingend nötig um das Connection-Pooling zu nutzen, ich wollte mir vielleicht Lernzeit sparen, denn die How_tos im commons_dbcp erscheinen mir als dort blutigen Anfänger etwas unverständlich und damit abschreckend.
mit super dankbaren Grüßen für gute Hinweise.
Takidoso
Zuletzt bearbeitet:
