Glassfish JDBC Verbindungspools ändern ohne neustart

[wasweisich]

Hallo

Mein Webservice soll auf eine Read-Only Datenbank zugreifen.

Meine Idee war dass die Datenbank auf einen anderen Server gepflegt und getestet wird, und wenn die Tests passen soll diese ins Produktivsystem kopiert werden (MS SQL 2008 Datenbank)

Mein Problem ist das ich im Glassfish eine JDBC Verbindung eingetragen habe und diese nur durch einen Neustart des Glassfisch Servers übernommen werden.

Um also die Daten zu übernehmen müsste ich den Glassfisch neu starten und alle Anwender fallen raus !

(Ich hoffe meine Frage ist klar genug formuliert, ich bin was Glassfish/ JDBC Connections betrifft Anfänger)


mfg

Reinhold

 

[FArt]

Mein Webservice soll auf eine Read-Only Datenbank zugreifen.

ok

Meine Idee war dass die Datenbank auf einen anderen Server gepflegt und getestet wird, und wenn die Tests passen soll diese ins Produktivsystem kopiert werden (MS SQL 2008 Datenbank)

Das verstehe ich nicht.

Mein Problem ist das ich im Glassfish eine JDBC Verbindung eingetragen habe und diese nur durch einen Neustart des Glassfisch Servers übernommen werden.

Ich nehme an, du hast eine Datasource deployt, die auf eine DB verweist.
So weit ich weiß, kann auch Glassfish hot deployen. Ich habe allerdings noch nicht versucht, einer Applkation im laufendne Betrieb die Datasource auszutauschen.

Vermutlich ist es praktischer, gewisse Änderungen nur während einer Downtime vorzunehmen bzw. (wenn eine Hochverfügbarkeit errreicht werden muss) einen parallelen Server mit einer neuen Version aufzusetzen und den alten Server auslaufen zu lassen.

 

[wasweisich]

Hallo

Erst mal danke für die Antwort, hot deployen klingt gut, mit dem Sichwort werde ich mal weitersuchen.

Wenn ich nichts finde werde ich die Idee mit dem zweiten Server aufgreifen.

Nochmal der Grund für dieses Vorgehen.

Ich möchte meine Datenbank in einen Pflegestand (hier tragen Datenpfleger Stammdaten ein) und einen Produktivbetrieb trennen.

Ich möchte aber nicht das alle Änderungen sofort in der Produktivdatenbank verfügbar sind.
Erst nach einer Freigabe soll der neue Stand für alle Anwender verfügbar sein.
Gleichzeit möchte ich im Problemfall schnell und einfach zu einem funktionsfähigen Vorgängerstand zurückwechseln können. Darum verschiedene Datenbankstände die ich austauschen will.

Ich bin ziemlich sicher das vor mir schon jemand das gleiche Problem hatte und eine Lösung hierfür gefunden hat.

mfg

Reinhold

ok


Das verstehe ich nicht.


Ich nehme an, du hast eine Datasource deployt, die auf eine DB verweist.
So weit ich weiß, kann auch Glassfish hot deployen. Ich habe allerdings noch nicht versucht, einer Applkation im laufendne Betrieb die Datasource auszutauschen.

Vermutlich ist es praktischer, gewisse Änderungen nur während einer Downtime vorzunehmen bzw. (wenn eine Hochverfügbarkeit errreicht werden muss) einen parallelen Server mit einer neuen Version aufzusetzen und den alten Server auslaufen zu lassen.

 

[FArt]

Ich möchte meine Datenbank in einen Pflegestand (hier tragen Datenpfleger Stammdaten ein) und einen Produktivbetrieb trennen.
Reinhold

Klar.

Ich bin ziemlich sicher das vor mir schon jemand das gleiche Problem hatte und eine Lösung hierfür gefunden hat.

Ja., das stimmt.

Ich möchte aber nicht das alle Änderungen sofort in der Produktivdatenbank verfügbar sind.
Erst nach einer Freigabe soll der neue Stand für alle Anwender verfügbar sein.
Gleichzeit möchte ich im Problemfall schnell und einfach zu einem funktionsfähigen Vorgängerstand zurückwechseln können. Darum verschiedene Datenbankstände die ich austauschen will.

Es gibt mehrere Ansätze dafür, abhängig von der verwendeten Datenbank, Infrastruktur und Architektur der Applikation (Webapp, Client-Server, Cluster,...), Menge und Art der Datenänderungen (mit oder ohne strukturelle Änderungen der DB), Dauer eines DB Updates und Verfügbarkeit der Applikation, bedingen die Datenänderungen Applikationsupdates und noch vieles mehr.
Ohne diese Informationen kann man keine sinnvolle Antwort auf deine Frage geben. Die Antwort könnte heißen: schreibe die Änderungen über Updateskripten in einer Transaktion in die DB und setze eventuelle Applikationschaches zurück (sehr einfach) oder arbeite mit einer geclusterten Anwendung, bei der du Benutzer über einen Balancer sanft migrieren kannst... oder eine Mischung daraus, oder ganz was anderes oder mal so mal so...

Prinzipiell ist es mit Downzeiten der Applikation natürlich leichter.

 

[wasweisich]

Hallo

Ich hatte gehofft ohne Datenbank - merge ( also mit einfachem Bakup und Restore ) klar zu kommen.

Ich werde jetzt mehrere Instanzen meines Services parallel laufen lassen und diese auf verschiedene Datenbankstände verweisen lassen.

Dann brauche ich nur noch eine Lösung wie ich dynamisch angebe welche Instanz gerade aktiv sein soll.

mfg

Reinhold

 

[FArt]

Ich hatte gehofft ohne Datenbank - merge ( also mit einfachem Bakup und Restore ) klar zu kommen.

Könnte sein.

Ich werde jetzt mehrere Instanzen meines Services parallel laufen lassen und diese auf verschiedene Datenbankstände verweisen lassen.

Eine mögliche Lösung, abhängig von Infrastruktur und Anforderungen.

Dann brauche ich nur noch eine Lösung wie ich dynamisch angebe welche Instanz gerade aktiv sein soll.

Interessant wäre auch, wie du die Datenkonsistenz in der laufenden Applikation sicherstellst (Caches, laufende Sessions/Calls im Verhältnis zu Transaktionsisolationslevel der DB, ...)