Ich würde dafür mal nicht die Generatoren von oben nehmen sondern unsere Gems. Wir haben einen kleinen Bungeecord Server mit einem Creative, einem Skyblock und einer Lobby. Wenn man votet, bekommt man einen Gem (virtuelle Währung). Diese Gems finden nun an allen Ecken ihre Verwendung: Scoreboard zum Beispiel, oder wenn man sich im Gem-Shop etwas freischalten möchte. (Mobspawning in Creative zb, so garantieren wir uns, dass Spieler ein bisschen spielen und nicht joinen und mit viel Entities lags machen).
Okay, das klingt nach einem sehr einfachen Fall. Das klingt bisher, als währe die Währung rein virtuell. Das heißt der Spieler besitzt keine Items oder ähnliches, welche die Währung repräsentieren, es ist einfach nur ein Wert, der irgendwo gespeichert und abgerufen wird. Das ist tatsächlich ein sehr einfacher Fall. Wenn das nicht stimmen sollte, dann gilt der Rest des Beitrages vermutlich nicht mehr.
Wenn ich das jetzt alles richtig verstehe gehe ich zum Beispiel wiefolgt vor:
in meiner MySQLManager klasse lege ich eine Klassenvariable für die Connection an und prüfe in jedem zugriff lediglich mit ner methode ob null, und wenn null, dann richte die Verbindung ein.
Nein, du nutzt, wenn du es absolut richtig machen willst, die DataSource. (weiter unten).
- ich speichere die Gems im Arbeitsspeicher wie du sagst und speichere sie nur regelmäßig / beim join/quit. Nachteil: ein Admin kann auf einem anderen Unterserver des Bungeecords nicht die aktuellsten Gems des Spielers einsehen, außer man arbeitet mit den messagingchannels und laggs bei Join und Disconnect wenn es im Hauptthread läuft. Und Datenverlust, wie du gesagt hast, wenn der Server crasht. Vorteil: nicht viele zugriffe auf db, also eigentlich ganz nice für alleinstehende Server.
Das ist zumindest eine Möglichkeit das Problem zu lösen. Die Nachteile, die du erwähnst, sind jedoch so gravierend, dass ich diese Lösung nicht in Betracht ziehen würde. Die Datenbank hat mit ein paar hundert Anfragen pro Minute überhaupt gar kein Problem.
- Ich benutze weiterhin überall mysql abfragen, verwende aber eigene threads und benutze ein lock, um zu verhindern, dass eine Race Situation entsteht. Wenn ein Spieler joint wird der Wert im Scoreboard dann zum Beispiel einfach später gesetzt, sobald er aus der MySQL gelesen wurde und der Hauptthread wird dabei nicht beeinflusst. Wenn der Spieler den Gemshop öffnet, öffnet dieser sich, sobald die aktuelle Gemzahl gelesen wurde und der Hauptthread wird nicht beeinflusst und so weiter.
Das ist schon theoretisch korrekt, aber "sobald die aktuelle Gemzahl gelesen wurde" ist halt leichter gesagt als getan. Die Fragen, die du dir z.B. stellen musst ist:
- Was wenn der Spieler versucht mehrere Inventare zu öffnen, während du gerade den Stand abfragst?
- Was wenn der Spieler offline geht?
- Sich ausloggt?
- Ganz viele andere komische Dinge tut
Das lässt sich in der Praxis dann nie alles korrekt absperren. Daher macht es oft Sinn, dass man einfach mit bestimmten Fehlern lebt und primär die Datenintegrität berücksichtigt. Wir ignorieren erstmal die Frage, wie sich das Inventar öffnet und gehen davon aus, der Spieler kauft sich etwas: In diesem Fall, startest du einen Thread im Hintergrund, welcher die Transaktion abwickeln wird. Nun brauchst du eigentlich eine atomare Compare And Set Query, welche zuerst prüft, ob der Spieler wirklich genug Gems hat und dann die Gems abzieht. Das Problem: Das sind zwei Operationen und sie sind nicht atomar. Da könntest du jetzt datenbankspezifische Locks verwenden, aber das führt für einen Anfänger zu weit. Daher ein anderer Vorschlag:
EDIT: Zur Frage, wie du nun den Gemstand bekommst, wenn sich das Invetar öffnet. Die lädst du halt einfach einmal vorher. Wenn der Spieler mehrfach klickt, dann öffnen sich halt mehrere verbuggte Menüs. Wenn du willst, kannst du den Spieler auch einfach blockieren, bis du die Daten hast oder einen generellen Cooldown von 5 Sekunden oder so verwenden. Es kann ja, in Kombination mit dem Rest, nur die grafische Darstellung kaputt gehen. Die Datenintegrität bleibt trotzdem sichergestellt.
Der Spieler kann nur auf einem Server gleichzeitig sein (das musst du sicherstellen, ich nehm das als gegeben an). Jeder Server kann nur genau EINE Transaktion gleichzeitig ausführen. Kaufen also 5 Spieler auf einem Server etwas, so wird das parallel bearbeitet. Daraus kannst du jetzt ableiten, dass es unmöglich ist, dass ein Spieler zwei Transaktionen gleichzeitig parallel am Laufen hat. Gut, also Problem gelöst. Gleichzeitig merkst du, dass du eigentlich nur einen Thread brauchst. Denn mehr als eine Transaktion gleichzeitig ist eh nicht möglich. Hierfür gibt es z.B. Worker Pools, die nur konstant einen Thread haben.
Dieser Thread prüft nun das Guthaben in der Datenbank, ändert es, und erzeugt dann einen Task im Mainthread, welcher die Transaktion abschließt und dem Spieler das Item gibt. Kleiner Anmerkung auch hier: Wenn zwischen dem Abziehen und dem Ausgeben des Items der Server crasht, verliert der Spieler die Gems und bekommt kein Item. Das zu verhindern, würde aber richtig richtig kompliziert werden. Aber solche Überlegungen sollte man sich immer machen und dann entscheiden, ob man diesen Fehler akzeptieren kann.
Damit ist das ganze relativ aufgeräumt. Du brauchst keine Locks und du hast aufgrund deiner Einschränkungen auch keine Probleme mit Race Conditions.
Wie genau der Spieler seine Gems bekommt, haben wir uns nun allerdings nicht angeschaut. Es ist auch hier möglich, dass der Spieler gerade ein Minigame gewonnen hat und einen Einkauf tätigt. Dann würde folgendes passieren (beispielhafte Zahlen zum Verständnis)
- Spieler hat aktuell 10 Gems
- Spieler öffnet Shop
- Spieler möchte Brecheisen für 5 Gems kaufen
- Thread liest aktuelles Guthaben mit 10 Gems aus Datenbank und bestätigt, dass 10 > 5
- Spieler gewinnt Minigame und bekommt 3 Gems, also 10 + 3 Gems. Datenbank schreibt 13 Gems
- Transaktionsthread berechnet 10 - 5 (weil ja 10 gelesen wurden) und schreibt 5 in die Datenbank
Der Spieler hat nun also seine 3 Gems verloren. Um das zu verhindern, muss also auch sichergestellt werden, dass der inkrement atomar ist. Also z.B. eine Query mit "UPDATE ... SET gems = gems +3" benutzt werden. Ein anderer Trick besteht darin die Updatequery grundsätzlich mit dem alten Zustand zu schreiben, also "UPDATE ... SET gems = gems - 5 WHERE gems = $erwarteterWert AND user = "luser"". Wenn du dann die Anzahl der betroffenen Zeilen prüfst, so hast du entweder 1, wenn es keinen Schreibkonflikt gab, oder 0, wenn zwischenzeitlich der Wert geändert wurde, in letzterem Fall wiederholst du die Query, bist du Erfolg hattest.
Das Konzept mit atomaren Zustandsänderungen ist allerdings auch im Prinzip die Definition von threadsicherer Programmierung, von daher ist das nicht so einfach. Wenn du allerdings letzteren Trick verwendest, dann solltest du bemerken, dass du sogar beliebig viele Transaktionen gleichzeitig durchführen können solltest. Die Beschränkung, die ich dir eingangs empfohlen habe, wäre also nicht länger nötig.
Spannend wird es dann nochmal, wenn die Spieler Gems handeln können, denn in diesem Fall musst du zwei Zeilen in deiner Tabelle atomar Updaten. Wenn du soweit kommst, solltest du dich mit "Transactions" im Kontext von Datenbanken beschäftigen, diese erlauben dir Änderungen entweder als Ganzes, oder gar nicht durchzuführen. Das ist aber auch nochmal ein kompliziertes (und spannendes Thema).
Hier würde jetzt das DataSource vermutlich auch zum Einsatz kommen, das du erwähnt hast. Ich hatte keine Zeit, das ausführlich zu lesen, werde mich aber dann selbstständig schlau machen
aber wenn ich das auf die Schnelle richtig verstanden habe, geht es dabei darum, die Anfragen mit nem Pool zu managen/bündeln (?)
Ja, man kann mit einer DataSource auch mehrere Verbindungen benutzen und ja, das ist ein Pool. Aber du kannst die DataSource auch so konfigurieren, dass sie nur eine einzige Verbindung enthält. Der Grund warum man das möchte ist der, dass die DataSource Implementierung sich selbstständig darum kümmert, dass deine Datenbankverbindung aktiv ist. Wenn du z.B. eine kaputte Query abschickst und die Connection dann an die DataSource zurück gibst, dann wird die DataSource sich darum kümmern, dass sie die Verbindung wieder in einen sauberen Zustand setzt. Wenn die Verbindung abbricht und du die Verbindung anforderst, dann baut die DataSource die Verbindung selbständig wieder auf oder gibt dir den Fehler. Entsprechend hast du auch das Problem nicht mehr, dass deine Datenbankverbindung null ist, denn das sollte sie nie sein. Du baust die Verbindung einmal am Anfang auf und nutzt sie dann. Nur, dass du das halt die DataSource erledigen lässt. Also das solltest du auf jeden Fall tun. DataSources können noch ein paar Dinge mehr, aber das braucht dich nicht interessieren.
Okay und zuletzt zum try-catch. Da habe ich jetzt nochmal verschiedene Seiten gelesen und auch die, die du mir geschickt hast. Aber was ich genau falsch gemacht habe, versteh ich nicht
Statement ist ein AutoClosable. Das heißt, du musst es schließen. IMMER!
Hier etwas code, der das illustriert.
try {
var statement = createStatement("foobar")
statement.irgendwasDa***ceptionWirft()
//möglichkeit 1: falsch
// wird nie aufgerufen, statement ressource nicht geschlossen, ressourcen leakt und irgendwann speicher voll
statement.close()
} catch (Egal dontcare) {
//möglichkeit 2: ohne nullcheck auch falsch, mit nullcheck echt hässlich
statement.close() // wenn es zu keinem fehler kommt, wird es doppelt aufgerufen, wenn createStatement() bereits einen Fehler erzeugt, hast du eine Nullpointerexception, daher nullcheck notwendig
} finally {
}
Wie du siehst, wird im Fehlerfall das Statement nicht mehr geschlossen. Das willst du nicht. In anderen Fällen, hast du mehrere Ressourcen und weißt nicht welche noch null sind, daher braucht man immer einen Nullcheck. Weil das alles Arbeit ist, gibt es try-with-ressources, damit schreibst du einfach nur noch:
try (var statement = createStatement("foobar")) { // wenn dieser block verlassen wird, kümmert sich java um den .close() aufruf
statement.irgendwasDa***ceptionWirft()
} catch (Egal dontcare) {
}
Falls das nicht ganz klar ist, dann einfach als Fausregel: Die willst niemals selbst
close() aufrufen. Jedes Objekt, dass du damit schließen musst, backst du in den Kopf eines try-with-ressources Blocks. Dann bist du auf der sicheren Seite. Eine Ausnahme, bei der das nicht geht, wäre deine DataSource, da diese einmal zu Beginn des Plugins erzeugt und erst am Ende geschlossen wird. In diesem Fall darfst du ausnahmsweise
close() in der onDisable Methode aufrufen und auf das try-with-ressources in onEnable verzichten.
