Architektur für DatabaseConnection in einer REST-Anwendung

Question

meine Frage scheint sehr einfach, aber es gibt einige Teilfragen, die eine tiefere Inspektion erfordert. Meine Frage: Was ist die beste Praxis/Architektur für die Datenbankverbindung zu handhaben?

Meine gefundenen Optionen:

1. Für jeden Rest ful Service mit Datenbank (DB) -Anforderungen eine neue Verbindung mit dem DB erstellen und diese nach den Abfragen wieder schließen.
2. Erstellen Sie eine Verbindung außerhalb des REST-Service und verwenden Sie diese für jede Abfrage .

Option 1 .: Ein Minuspunkt sind die Kosten für etablish und schließen Sie die Verbindung für jede Anfrage.

Option 2 .: Weiß nicht, ob es funktioniert. Ich habe für den Web Service Lifecycle recherchiert, um zu überprüfen, wie dies funktioniert, weiß aber nicht, ob die Instanzen nach dem Ende des Web Service am Leben bleiben. Weiß auch nicht, ob es eine gute Übung ist, denn es könnte Ereignisse geben, die die Verbindung zerstören. Ein letztes Problem ist, dass die Anfragen blockweise sein könnten (also das Konzept der Threads zerstört).

Hoffen Sie, dass Sie mir ein wenig mit dieser Architektur helfen konnten.

Greets,

Nik

Answer 1

Wenn Sie eine pro Abfrage/Transaktion zu erstellen, ist es viel einfacher, "Schließen", um die Verbindungen zu verwalten.

Ich kann sehen, warum der gesunde Menschenverstand diktiert, dass Sie einen öffnen und es durchweg verwenden sollten, aber Sie werden Probleme mit unterbrochenen Verbindungen und Multithreading bekommen. Ihr nächster Schritt wird also sein, einen Pool von etwa 50 Verbindungen zu öffnen und alle offen zu halten, um sie an verschiedene Prozesse weiterzuleiten.

Wenn Sie eine Verbindung öffnen, wenn Sie sie benötigen, und sie nach Abschluss der Verbindung entfernen, wird die Verbindung nicht wirklich geschlossen, sondern nur an den Verbindungspool zurückgegeben, damit sie erneut verwendet werden kann.