Grundsatzfrage zu Datenbankverbindungen

[ProggersWorld]

Guten Morgen Zusammen,

letztens habe ich mir auf YouTube ein Tutorial angeschaut. Hierbei handelte es sich um ein Point Of Sale Programm. Nun hat er die einzelne Fenster so programmiert dass beim öffnen des Fensters eine neue Datenbankverbindung aufgebaut wird. Ist das eine gängige Praxis? Wie wird das bei große ERP Systeme gehandhabt? Ich war bisher der Meinung dass beim Login eine Verbindung erzeugt wird und somit dieser Instanz in den unterschiedlichste Fenster per Factory Klasse o.ä. jederzeit aufrufbar ist.

Schönes WE,
Raymond

 

[KonradN]

Also ich finde es eine Best Practice, dass man immer eine neue Verbindung aufbaut und die Verwaltung der Verbindungen einem bestehenden Code überlässt.

Kommen wir erst einmal zu den Problemstellungen:
a) Eine Connection, die geöffnet wurde, muss nicht immer offen bleiben. Es kann ein Verbindungsabbruch geben oder ein einfachen Timeout. Dann wäre die Connection geschlossen und nicht mehr zu verwenden.
b) Eine Applikation macht oft Dinge in mehreren Threads. Eine Verbindung kann aber immer nur einmal benutzt werden.

Das könnte man also selbst lösen:
a) Vor Nutzung der Connection prüfst Du, ob diese noch in einem brauchbaren Zustand ist. Ist dies nicht der Fall, öffnest Du die Connection neu.
b) Du machst eine Verwaltung für die Connection, so dass immer nur ein Thread diese ein Mal nutzen kann.

Wie sowas dann am Besten zu lösen wäre, kann man sich dann im Detail überlegen. Da kommt man dann schnell zu einer Lösung, bei der man einen Check der Verbindung hat und man braucht einen klaren Punkt, bei dem diese Prüfung zu machen ist. Da die Connection erneuert werden könnte, wäre es sowas wie eine Anforderung einer Connection.
Dann braucht man ggf. mehrere Connections. Also muss man auch mehrere Connection verwalten können.

Da dies ein generelles Problem ist, wurde dies natürlich bereits gelöst. Das nennt sich dann Connection Pool. In .Net ist es üblich, dass dies direkt vom Treiber implementiert wird. In der Java Welt ist dies (meist) eine eigenständige Implementierung.

A Simple Guide to Connection Pooling in Java | Baeldung

A quick overview of several popular connection pooling solutions, plus a quick dive into a custom connection pool implementation

www.baeldung.com

Dieser Artikel zeigt auch die drei am stärksten genutzten Implementationen.

 

[ProggersWorld]

Hallo KonradN,

vielen dank für deine ausführliche Antwort. Wieder was gelernt. 👍
😀

 

[KonradN]

Ach so - die Nutzung selbst habe ich nicht beschrieben:

Wann immer eine Connection gebraucht wird, dann wird diese vom Connection Pool angefordert. Direkt nach der Nutzung wird diese dann geschlossen und damit an den Pool zurück gegeben. (Und ist damit das beste Beispiel für das try-with-resources)

 

[yfons123]

du kannst auch nach single source of truth gehen dh du hast einen server und der hat 1e verbindung zum sql server und sonst niemand

jeder der was speichern will muss beim server anfragen ob das gespeichert werden darf und da ist halt dein server der aufpasser der entscheidet ob das zulässig ist oder nicht was da ankommt

 

[KonradN]

du kannst auch nach single source of truth gehen dh du hast einen server und der hat 1e verbindung zum sql server und sonst niemand

Kannst Du irgend ein Szenario skizzieren, bei dem das so sinnvoll wäre?

 

[temi]

du kannst auch nach single source of truth gehen dh du hast einen server und der hat 1e verbindung zum sql server und sonst niemand

Das war doch nicht die Frage, oder? Die lautete, wie man die Verbindung(en) zur DB handhabt und wurde von @KonradN ausführlich beantwortet.

Was du beschreibst ist etwas anderes und hat damit nicht unbedingt etwas zu tun, denn auch der Server muss evtl. mehrere Verbindungen zur DB handhaben.

 

[KonradN]

Was du beschreibst ist etwas anderes und hat damit nicht unbedingt etwas zu tun, denn auch der Server muss evtl. mehrere Verbindungen zur DB handhaben.

Ein Datenbankserver kann eigentlich immer mehrere Verbindungen handhaben. Selbst die Embedded Datenbanken können das. Daher hat mich das total gewundert und ich sehe einfach keinerlei Sinn bei Datenbanken einen solchen Ansatz zu nutzen.

 

[temi]

Ein Datenbankserver kann eigentlich immer mehrere Verbindungen handhaben. Selbst die Embedded Datenbanken können das. Daher hat mich das total gewundert und ich sehe einfach keinerlei Sinn bei Datenbanken einen solchen Ansatz zu nutzen.

Der DB-Server schon, aber von dem hatte ich nicht geschrieben, auch wenn das offenbar nicht klar herüber gekommen ist. Es ist ja durchaus üblich, dass Clients nicht direkt mit einer DB kommunizieren, sondern über einen weiteren Server, z. B. REST-Service.

Aber wie geschrieben, das war nicht die Frage.

 

[KonradN]

Der DB-Server schon, aber von dem habe ich nicht geschrieben, auch wenn das offenbar nicht klar herüber gekommen ist. Es ist ja durchaus üblich, dass Clients nicht direkt mit einer DB kommunizieren, sondern über einen weiteren Server, z. B. REST-Service.

Aber wie geschrieben, das war nicht die Frage.

Aber das ist doch nicht das, was @yfons123 geschrieben hat. So ein REST-Service hätte ja keine Beschränkung auf eine Verbindung zur Datenbank. So ein REST Service ist nach außen ja auch nicht auf eine Verbindung beschränkt.

Und natürlich ist da auch keinerlei Beschränkung auf einen REST-Service (Server). Das ist in der Regel etwas, das auch skaliert werden kann. Da gibt es ja extrem viele Möglichkeiten. Daher ist das auch explizit kein "single source of truth": https://en.wikipedia.org/wiki/Single_source_of_truth

Daher auch explizit meine Nachfrage. Das, was da geschrieben wurde, macht so einfach keinen Sinn! Unabhängig von der genauen Fragestellung - aber wo ist die Relevanz bei Datenbanken generell? Single point of truth ist bei Datenbanken wichtig, wenn man Daten verteilt speichert. Aber da hat man dann nicht einen Server mit einer Verbindung sondern eine Datenbank (-Instanz, -Server, ....) hat die Verantwortung für etwas. Die Information mag dann verteilt werden aber Änderungen und so obliegen einer zentralen Stelle.

Daher wäre es einmal interessant, wenn da etwas mehr kommen würde. Auf will @yfons123 hinaus bei der Antwort?

 

[temi]

Aber das ist doch nicht das, was @yfons123 geschrieben hat.

So hatte ich es zumindest verstanden...

 

[mihe7]

So hatte ich es zumindest verstanden...

Ich auch

 

[KonradN]

Also ich wollte nicht unterstellen, dass du es nicht so siehst und du mich anlügst oder so.

Ich kann es nur eben leider so nicht erkennen. Daher war mein Versuch, einfach zu erläutern, was ich da so sehe. Wäre natürlich nett, wenn es diesbezüglich auch von euch eine Erläuterung gäbe. Das wäre dann ein netter Meinungsaustausch.

Kommt das evtl. aus eine Microservice / Docker Sicht, wo man eine Datenbank mit Service hat und der Service sowas wie der „Master“ ist?

Denn es gibt ja auch durchaus andere Konstellationen. In nicht zu ferner Vergangenheit war das produktive Umfeld ein DB Cluster (eigentlich Zwei mit Mirror in zweitem RZ) und einiger Server die dann über Loadbalancer angesprochen wurden. Ein Server (Master) mit einer Datenbankverbindung ist da halt so nicht vorhanden - auch wenn natürlich die Datenbanken von außen nicht angesprochen wurden. Das nur noch mal zur Erläuterung meiner Sicht.

Ich will euch nicht überzeugen, aber ich will eure Sicht / euer Verständnis mit nachvollziehen.

 

[mihe7]

@KonradN, ich hatte einfach seinen Satz so verstanden:

dh du hast einen server und der hat 1e verbindung zum sql server und sonst niemand

Heißt für mich: es gibt einen Client, der greift auf einen Server zu und dieser Server hat dann "eine" Verbindung zur DB.

 

[temi]

@KonradN, ich hatte einfach seinen Satz so verstanden:

Heißt für mich: es gibt einen Client, der greift auf einen Server zu und dieser Server hat dann "eine" Verbindung zur DB.

Volle Zustimmung. Den Rest hatte ich ignoriert...

Aber, um mich zu wiederholen, das ändert nichts daran, dass auch der/die/das "Server/Loadbalancer/blablub" eine oder mehrere Verbindungen zur DB benötigt und wir damit wieder bei der bereits beantworteten Ausgangsfrage angekommen sind. In der geht es nur darum, wie man das mit der Verbindung zur DB normalerweise macht und nicht darum, welcher Teil in der Softwarearchitektur das übernimmt.

 

[KonradN]

Danke, nun verstehe ich auch eure Sicht.

 

[yfons123]

deutsch war noch nie meine stärke