RageMP Pool Verbingung?
Wo, wie oder was.
Wo/Wie bekomme ich die Pool daten.
Was sind überhaupt die Pool daten.
Kann mir da jmd helfen?
https://pastebin.com/AtUeHiWb
Link des Codes
1 Antwort
Ein Pool ist nichts Anderes als eine bereits bestehende Sammlung von Dingen, auf die Du zurückgreifen kannst, um sie nicht jedes Mal neu erstellen zu müssen. Eine Datenbankverbindung aufuzubauen ist ziemlich aufwändig, deshalb kümmert sich ADO.NET von alleine um das Pooling der Verbindungen.
Das ADO.NET-Pooling schaut dann (grob gesagt) nach, ob gerade eine Verbindung ungenutzt ist und zu den Einstellungen passt. Wenn ja, nutzt es diese Verbindung und teilt der Datenbank die nötigen Infos dazu mit, wenn nein, öffnet es eine neue Verbindung und legt sie im Pool ab.
Die ADO.NET-Variante tut aber noch viel mehr und vor allem ist das zig fach getestet und erprobt.
Daher solltest Du NIEMALS einen eigene DB-Connection-Pool bauen!!! Jedes Datenbank-Framework, sollte irgendwann auf die Grundlage, die ADO.NET darstellt, zurückgreifen und damit auch den Pool nutzen. Du brauchst dir um das Pooling also keine Gedanken machen, das ist standardmäßig aktiviert.
Einfach eine Connection öffnen, tun, was Du tun willst und direkt wieder schließen + Dispose aufrufen bzw. direkt using nutzen.
Allgemeine Probleme bei deinem Code:
Eine Connection sollte nicht einfach so offen bleiben, das schreit nach Problemen, da eine Connection noch massig zusätzliche Dinge mit sich bringt, die die Datenbank selber im Hintergrund tut. Eine Connection sollte immer so früh wie möglich wieder geschlossen werden, um das Pooling (ohne die möglichen Probleme) kümmert sich dann ADO.NET von alleine.
Ach und solange Du die Connection nicht schließt, bleibt sie im Pool gesperrt, irgendwann hast Du also ein Pool mit gesperrten Connections und der bringt dir nichts.
Vermeide statisches Zeug, damit meine ich auch Konstanten. Ein ConnectionString sollte nach Möglichkeit geändert werden können, z.B. über eine config-Datei. Dabei sollte aber nicht die Methode selber die Config lesen (Single Responsibility Principle), das sollte woanders (z.B. einmal beim Start der Anwendung) geschehen. Die Methode bekommt das dann per Dependency Injection mitgeteilt, die naheliegenste Variante dafür wäre, den ConnectionString als Parameter mit zu geben (ja, das ist Dependency Injection), es gibt aber noch massig andere Konzepte, wie z.B. ein IConnectionStringProvider-Interface, dessen Implementierung dann die Config liest.
Das mit der DependencInjection gilt übrigens auch für die Pool-Größe. Die würde ich z.B. per Konstruktor-Parameter entgegen nehmen und dann readonly speichern.
Exceptions sollten NIE, NIE, NIEMALS NIE einfach so gefangen werden und das, was Du da tust, ist "einfach so fangen". Eine Exception sollte erst dann gefangen werden, wenn Du das Problem auch wirklich behandeln kannst, oder der Fehler aus guten Gründen nicht weiter nach oben fliegen darf, wie z.B. beim Button-Click. In letzterem Fall sollte das dann auch geloggt werden.
Ich schreibe sogar fast nie ein Catch, normalerweise landet das in einer verallgemeinerten Behandlung für Hintergrund-Aktionen, das kümmert sich dann auch um die Behandlung von unerwarteten Fehlern und loggt fleißig mit.
Die Konsole ist KEIN zuverlässiges Logging. Dafür gibt es viele Frameworks, die unter Anderem auch in die Konsole, aber auch überall sonst (Datei, Datenbank, Mail, Wep-API, Windows-Event-Log, etc.) hin schreiben können, alles einstellbar, sodass Du dich beim Logging selber nicht mehr darum kümmern musst.
Ich kann z.B. Serilog empfehlen, das kann gefühlt alles und ist allgemein sehr klug aufgebaut.