Connection Pool

S

Schrödi

Mitglied
Hallo,

ich habe eine allgemeine Frage zum Connection Pool.

Ich habe eine Desktopanwendung mit Datenbankanbindung geschrieben. Das Tool wird zukünftig von vielen Usern benutzt. Da stellt sich das Problem des Connectionhandlings. Hierfür gibt es ja viele fertige Klassen.

Nun meine Fragen:
Ist hier möglich ein ConnectionPool zu nutzen? Die Anwendung läuft ja schließlich bei den Usern lokal.
Wenn ja, woher weiß das Tool / die Klasse wieviele Connections bereits genutzt werden?

Gruß Schrodi
 
Commons Pool oder C3P0 sind die Dinge, die du dir anschauen solltest. Ansonsten stellt sich die Frage wo die DB liegt. Wenn du einen Richclient mit lokaler DB hast ist das recht einfach, weil vermutlich eh nur eine mit der App arbeitet. Liegt die DB auf nem externen Server gilt clientseitig ähnliches, allerding musst du dann deinen DB Server sauber konfigurieren.

REINHAUN!
 
Ok,

die DB liegt auf einem extra Server. Konfigurieren ist so eine Sache. Da komme ich schlecht dran. Ich arbeite in einem Intranet und der Server wird zentral verwaltet.

Was für Einstellungen müssen denn hier explizit vorgenommen sein?
 
Soweit ich es verstehe ist connectionPooling immer dann von Nöten wenn Verbindungen häufig aufgebaut und wieder fallen gelassen werden. Dies ist z.B. bei 3-Tier-archetekturen der Fall. Dabei würde der Client nicht selbst SQL-Anfragen stellen sondern über eine Serverschicht, die sich mittels Connectionpooling dann an den DB-Server mit der SQL-Anweisung richtet.
Hat man eine 2-Tier Architektur, also Client ruft direkt DB-Server an, könnte es IMHO völlig ausreichend sein, wenn der Client seine Conneciton ohne Pooling hält. Es ist jedoch dann sicher zu stellen, dass die DB nicht die Verbindung eigenständig wegen Untätigkeit des Clients kappt. Eine solche 2-Tierarchitektur ist aber mehr was für kleine Systeme und wenn eine Verbindung über Intet geht sollte man sich lieber für eine drei Tier-Architektur durchringen allein schon wegen Sicherheitsaspekten.
 
Mir drängt sich immer mehr der Gedanke auf, dass ich das Pooling falsch verstanden habe.
Ich dachte, dass es dazu dient, dass sich viele Benutzer mit dem clientseitig laufenden Programm wenige Connections teilen (quasi eine Art Warteschkange), und nicht die Verbindungen offen zu halten.

Aus der php Programmierung kenne ich, dass die Verbindung möglichst schnell wieder geschlossen werden sollte, wenn diese nicht mehr benötigt wird, damit diese wieder zur Verfügung steht.

Demnach habe ich es bisher auch so bei Java gehalten. Jedesmal, wenn ich einen DB Zugriff mache, schließe ich die Verbindung nach erfolgtem Datenaustausch wieder.
 
Deswegen wäre es ja wichtig zu wissen wie dein Programm aufgebaut ist.

Wie willst du Poolen wenn deine Clients direkt eine Verbindung zum Server herstellen. Der Verbingungsaufbau, inbesondere zu entfernten Datenbanken kann schon eine ganze Weile dauern. Daher kann ein Connection Pool ein Programm beschleunigen. Die Connection immer zu schließen ist richtig. Das wird auch beim Pool so gehandhabt. Nur dass ein Wrapper dafür sorgt, dass die Connection nicht direkt geschlossen, sondern nur an den Pool zurückgegeben wird.
 
Es ist eigentlich ein relativ einfach gehaltenes Tool.
Den Usern wird es per Webstart zur Verfügung gestellt. Über ein Formular können die User eine zentrale Datenbank füllen, über eine andere Maske werden die Daten ausgewertet und in tabellarischer, sowie Diagrammform aufbereitet und kompakt dargestellt (Datenerfassung und Auswertung).
Zur Zeit läuft das Tool auf php Basis, daher weiß ich, dass etwa 700 Benutzer das Tool nutzen werden. Da der php Server nur eine virtuelle Maschine ist, ist dieser mit der Berechnung der Datenmengen überlastet ist (max. 120 Sek. Scriptlaufzeit), ist der Umstieg auf Clientseite unumgänglich.

Für die DB Verbindung habe ich bisher Spring genutzt.
 
schrodi hat gesagt.:
Mir drängt sich immer mehr der Gedanke auf, dass ich das Pooling falsch verstanden habe.
Ich dachte, dass es dazu dient, dass sich viele Benutzer mit dem clientseitig laufenden Programm wenige Connections teilen (quasi eine Art Warteschkange), und nicht die Verbindungen offen zu halten.
Zum Vergrößern anklicken....
Ich denke das hast Du ganz richtig verstanden :-)
Aus der php Programmierung kenne ich, dass die Verbindung möglichst schnell wieder geschlossen werden sollte, wenn diese nicht mehr benötigt wird, damit diese wieder zur Verfügung steht.
Zum Vergrößern anklicken....
Bei PHP hast Du ziemlich automatisch eine 3 Tier Architektur
Clientseitig ist der Browser, Anwendungsserver ist ein WEB-Server mit PHP und dann noch einen Datenbankserver (wobei Web-Server und DB-Server physisch auch dieselbe Kiste sein könnten, dennoch ist es ein 3 Schichtenmodell)

Demnach habe ich es bisher auch so bei Java gehalten. Jedesmal, wenn ich einen DB Zugriff mache, schließe ich die Verbindung nach erfolgtem Datenaustausch wieder.
Zum Vergrößern anklicken....
In Java wird es wie schon von Zeja gesagt genauso gemacht.
Wichtig ist aber zu wissen, ob Du 2 Schichten oder 3 Schichten hast. Unterhält sich das Clientprogramm direkt über SQL mit der DB, müsste das Connectionpooling theoretisch der DB-Server organisieren. Ob das von DB-Servern heutzutage selbst erledigt wird entzieht sich meiner Kenntnis. Ein Connectionpool direkt auf einer jeden physischen Client-Kiste halte ich für nicht sinnvoll, da normalerweise nur ein User pro Client-Rechner gleichzeitig arbeitet.
Also Frage hier: hast Du nun 2 oder drei Schichten?

(2 Schichten machen IMHO nur Sinn, wenn man eine überschaubare Anzahl User hat)
 
Zuletzt bearbeitet:
Ok, demnach habe ich nur zwei Schichten. Mein Tool kommunziert direkt mit der DB.

Ist es möglich, die 3. / mittlere Schicht auf einem IIS Server (Webserver) laufen zu lassen? Ich habe leider keinen administrativen Zugriff auf die Maschinen, sodass ich Services nachinstallaieren könnte.
 
Hi,
ich komme nicht weiter.
Hier noch ein paar Ideen:

Ist es vielleicht möglich ein Servlet als Connection Pool zu nutzen?

Eine andere Möglichkeit, die ich sehe, ist eine Schnittstelle via php. Was haltet ihr davon?
php könnte die DB-Anbindung übernehmen und die Anfragen via XML oder CSV-Text zur Verfügung stellen.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück