PDA

View Full Version : Datenbankverbindung



KM
30-04-07, 15:42
Ich mache gerade meine ersten Versuche mit JSF/MyFaces. Als erstes wollte ich eine einfache Login-Applikation erstellen. Ich möchte also per JDBC auf die iSeries-Datenbank zugreifen und die Verbindung für spätere Requests offen lassen. Jetzt habe ich herausgefunden, dass es hierfür entweder die Möglichkeit gibt über Connection-Pooling oder ich erstelle eine Connection pro Session und speichere das Connection-Objekt als Session-Variable.
Da später doch viele Benutzer damit arbeiten werden, bin ich unschlüssig welche Variante ich wählen soll. Kann mit jemand evtl. die Vor- und Nachteile beider Varianten aufzeigen ? Beim Connection-Pooling muß ich ja immer einen festen Benutzer zur Herstellung der Verbindung benutzen. Wie mache ich da die User Authentification für den Benutzer, der gerade den Request sendet ? Wie sieht es bei evtl. abnormalen Beendigungen von Requests aus ? Bleiben beim Connection-Pool die Verbindungen dann ewig bestehen ? Bei der Session-Variante wird die Verbindung ja beim Schließen des Browsers beendet.

Irgendwie tendiere ich momentan eher zur Variante mit der Session-Variablen.

Gibt es irgendwelche Meinungen/Erfahrungen dazu ?

Gruß,
KM

BenderD
30-04-07, 16:22
Hallo,

Connection Pool:
pros:
- zentralisiertes Connection Handling
- fertige Komponenten verfügbar (Achtung der Dollschachtel Kram taugt auch hier nichts!), selbige kümmern sich um keep alive, aging und vieles mehr.
- vereinfachte Programmierung Transactions (pro Transaction eigene Connection
- einfacherer Umstieg zu ORM (Hibernate und Co)
- bessere Performance durch wirksameres Caching von prepared Statements möglich
- state of the Art
contra:
- Access Controll wandert in die Application (ist aber Java typisch)

Connection in der Session:
- wird in externen Reviews meist bemängelt
- komplexeres Transaction Management bei überlappenden Transaktionen
- Fehler anfällig im Multithreading
- Je nach Datenbank ist connecten teuer (bei AS400 eher nicht)
- Connections vergammeln
- Keine Komponenten verfügbar

Summa Summarum spricht fast alles für den Pool.

mfg

Dieter Bender


Ich mache gerade meine ersten Versuche mit JSF/MyFaces. Als erstes wollte ich eine einfache Login-Applikation erstellen. Ich möchte also per JDBC auf die iSeries-Datenbank zugreifen und die Verbindung für spätere Requests offen lassen. Jetzt habe ich herausgefunden, dass es hierfür entweder die Möglichkeit gibt über Connection-Pooling oder ich erstelle eine Connection pro Session und speichere das Connection-Objekt als Session-Variable.
Da später doch viele Benutzer damit arbeiten werden, bin ich unschlüssig welche Variante ich wählen soll. Kann mit jemand evtl. die Vor- und Nachteile beider Varianten aufzeigen ? Beim Connection-Pooling muß ich ja immer einen festen Benutzer zur Herstellung der Verbindung benutzen. Wie mache ich da die User Authentification für den Benutzer, der gerade den Request sendet ? Wie sieht es bei evtl. abnormalen Beendigungen von Requests aus ? Bleiben beim Connection-Pool die Verbindungen dann ewig bestehen ? Bei der Session-Variante wird die Verbindung ja beim Schließen des Browsers beendet.

Irgendwie tendiere ich momentan eher zur Variante mit der Session-Variablen.

Gibt es irgendwelche Meinungen/Erfahrungen dazu ?

Gruß,
KM

KM
02-05-07, 16:24
Danke für diese Infos. Dann werde ich mal versuchen das so umzusetzen.

Gruß,
KM

BenderD
02-05-07, 17:12
Hallo,

da gabs mal einen Artikel von mir dazu im Midrange Magazin im Mai 2004, der müsste eigentlich noch ziemlich aktuell sein. http://www.***************.de/pms/archiv/mm/mm2004/MM0405.pdf
Im übrigen solltest du darauf achten, dass in die JSPs keine Java Scriptlets und kein Java Skript reingehören. Das lässt sich alles mit Tags machen, von denen man die mit Datenbankzugriffen auch meiden sollte. Die JSPs sollten ihre Daten vollständig aus Beans beziehen, die ihnen aus der drunter liegenden Logik Schicht im Request oder Session bereit gestellt werden.

mfg

Dieter Bender



Danke für diese Infos. Dann werde ich mal versuchen das so umzusetzen.

Gruß,
KM

RobertPic
04-05-07, 16:57
Ich habe erst jetzt wieder mal reingeschaut, die Entscheidung in Richtung Connectionpools dürfte ohnehin gefallen sein.


... Jetzt habe ich herausgefunden, dass es hierfür entweder die Möglichkeit gibt über Connection-Pooling oder ich erstelle eine Connection pro Session und speichere das Connection-Objekt als Session-Variable. ....

Hier noch ein weiterer Nachteil dieser Methode:
Diese Lösung ist dann schlecht skalierbar bzw. clusterfähig. Die Connection ist schlecht serialisierbar. Wenn die Arbeit auf mehrere Server verteilt wird, sind die Sessiondaten nicht austauschbar.

Bei Pools sind i.d.R. weniger Connections gleichzeitig offen, als wenn jede Session seine eigene Connection hält.

Ein Beispiel aus meinem jetztigen Projekt (Internetanbindung Webshop, Katalog):

Das Bewertungsmodul (GH-Preisfindung, Cobol via stored Procedure) wird meistens von nur einer Connection gehalten/abgewickelt - auch wenn bis zu 80 Kunden im Webshop arbeiten.

Bei der "selber halten" Methode wird die Procedure 80x offen gehalten oder jedesmal neu geöffnet.

Robert

BenderD
04-05-07, 19:08
Halo,

das mit Load Balancing (Stichwort Serialisierung) ist ein wichtiger Punkt, wobei man dann natürlich auch ResultSets etc im Auge haben muss.

Die Anzahl der Connections ist für eine AS400 eher kein Problem, obwohl man das in Reviews meist aufs Brot geschmiert bekommt (ich habe da so meine Erfahrungen mit einem Projekt in das ich mal als "Feuerwehr" geholt wurde) meine kleine 170 hat da locker 100 weggesteckt (solange die nicht alle gleichzeitig was wollen) und Produktions nähere Systeme haben da eigentlich nur das Paging kaum merkbar erhöht, zum Wegknicken habe ich die so nicht bekommen.

mfg

Dieter Bender


Ich habe erst jetzt wieder mal reingeschaut, die Entscheidung in Richtung Connectionpools dürfte ohnehin gefallen sein.



Hier noch ein weiterer Nachteil dieser Methode:
Diese Lösung ist dann schlecht skalierbar bzw. clusterfähig. Die Connection ist schlecht serialisierbar. Wenn die Arbeit auf mehrere Server verteilt wird, sind die Sessiondaten nicht austauschbar.

Bei Pools sind i.d.R. weniger Connections gleichzeitig offen, als wenn jede Session seine eigene Connection hält.

Ein Beispiel aus meinem jetztigen Projekt (Internetanbindung Webshop, Katalog):

Das Bewertungsmodul (GH-Preisfindung, Cobol via stored Procedure) wird meistens von nur einer Connection gehalten/abgewickelt - auch wenn bis zu 80 Kunden im Webshop arbeiten.

Bei der "selber halten" Methode wird die Procedure 80x offen gehalten oder jedesmal neu geöffnet.

Robert