Optimise economy balance persistence

[gtolontop]

Petit résumé de la PR:

Optimise la persistance des soldes économie en regroupant les écritures DB des balances modifiées.

Étape nécessaire afin que la PR soit fini (si PR en draft)

• Suivre le Code de Conduite
• Enlever tous les imports non utilisés
• Bien documenter la feature
• Fournir un profileur (non demandé pour cette PR)
• Avoir une milestone associée à la PR (2.5.0 à assigner)
• Valider tout les checks
• Tester et valider la feature/changement

• Les Issues corrigée(s) en commun :
  Fixes [BUG] Optimisation de EconomyManager.setBalance #1332

Decrivez vos changements

EconomyManager écrivait en DB à chaque changement de solde via playersDao.createOrUpdate, notamment depuis setBalance, addBalance et withdrawBalance.

Cette PR garde les soldes à jour en mémoire immédiatement, marque uniquement les comptes modifiés comme à sauvegarder, puis persiste ces comptes en batch avec saveAllBalances() :

• à l'arrêt de la feature, via le cycle de sauvegarde existant ;
• périodiquement via un autosave, pour limiter la perte possible en cas de crash.

Le cache utilise aussi computeIfAbsent pour conserver les nouveaux comptes en mémoire avant leur première sauvegarde. En cas d'erreur pendant la sauvegarde batch, les comptes concernés sont remis dans la liste à sauvegarder.

[AxenoDev]

au lieu de sauvegarder tout les x temps, pourquoi tu save pas juste a la db au moment ou le plugin se desactive

[iambibi]

C'était marqué dans l'issue

[gtolontop]

au lieu de sauvegarder tout les x temps, pourquoi tu save pas juste a la db au moment ou le plugin se desactive

C’est déjà fait xd au save() de la feature, donc à la désactivation du plugin, saveAllBalances() flush les balances modifiées

L’autosave est volontaire en plus du shutdown save ça évite de perdre toutes les modifications depuis le démarrage si le serveur crash/kill ou si l’arrêt ne va pas jusqu’au bout. Et il ne sauvegarde pas tous les balances à chaque fois, seulement les UUID marqués dirty depuis la dernière sauvegarde :)

[AxenoDev]

Le serveur n'est pas cense etre kill ou crash, meme il ne sera jamais kill...

[iambibi]

Ben après il peut crash oui. Mais il est tjr éteint à 2h donc cv

[gtolontop]

Même si le serveur n’est pas censé crash il peut crash mdrrrrr l’autosave limite la perte si ça arrive et dans tous les cas le coût en perf est faible on ne save pas tous les comptes seulement les dirty en batch

[iambibi]

Tu appelles quoi un compte dirty?

[gtolontop]

Dirty = modifié depuis le dernier save DB
On garde l’UUID dans dirtyBalances et au prochain save on persiste seulement ces comptes

[AxenoDev]

Le probleme, est que la le lag a lieu lors de la premiere connexion des joeurs, c'est un moment que l'on avait fait avec 50bots de souvenir, et le lag venait du save a la db, donc la si je comprends bien, a un moment, le serveur va lag parcequ'il save toutes les donne dans la db a un moment x

[iambibi]

Fin et déjà pour qu'on valide le problème, il faudra que tu donnes un jar de ton plugin, on fait un teste avec 50-100 joueurs, et on attends jusqu'au moment où le scheduler s'exécute pour save la db, et on tentera

[AxenoDev]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

[Shoccapik]

Le satan qui se réveille avec le full vibecoding qui fait mal

[gtolontop]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

MDRRRRR, elle est vraiment niquel ma PR je vois pas le soucis + c'est pas du vibecoding mais j'avoue que mon code a une vibe très propre :)

Ta mal pris le faite que tu es tort ici ?

ou ici ?

[gtolontop]

Le satan qui se réveille avec le full vibecoding qui fait mal

Très propre se vibecoding en tous cas

[gtolontop]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

Dis-moi, qu'aurais-tu fait différemment ?

[AxenoDev]

Donc pourquoi il y a ecris CODEX dans ta PR ....
Ne me prends pas pour un con non plus

[AxenoDev]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

Dis-moi, qu'aurais-tu fait différemment ?

Honnetement, bcp de chose, mais si tu "ne vibecode pas" chaque developpeur fait differemment donc je n'aurais pas fait pareil que toi

[iambibi]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

MDRRRRR, elle est vraiment niquel ma PR je vois pas le soucis + c'est pas du vibecoding mais j'avoue que mon code a une vibe très propre :)

Ta mal pris le faite que tu es tort ici ?

ou ici ?

Tu mets tout sur le principe de la raison? Pourquoi ?
Tu as des choses à montrer?
Avoir tort n'est pas négatif le temps que la personne explique pourquoi elle a tort.

[iambibi]

Fin je dis pas ton initiative est bonne mais quand on voit le préfixe [codex], on a tout de suite moins envie de la merge, de plus tu as une très bonne connaissance du plugin. Tellement une bonne connaissance que tu ajoutes même des tests, des appels à OMCLogger (qui est totalement nouveau et que je doute que tu l'as vu sans une IA qui a codé). Fabuleux !

[AxenoDev]

Bon @gtolontop, si c'est pour faire du vibecoding sur le projet ce n'est pas la peine de venir faire une PR.

MDRRRRR, elle est vraiment niquel ma PR je vois pas le soucis + c'est pas du vibecoding mais j'avoue que mon code a une vibe très propre :)

Ta mal pris le faite que tu es tort ici ? ou ici ?

Voila a quoi je penses quand je vois ton message