Magasin

Le Magasin L'interface définit une abstraction de stockage clé-valeur par session pour socketio4j. Elle permet aux transports, aux espaces de noms et au code utilisateur de conserver de petits éléments de métadonnées à l'échelle de la session tels que les identifiants d'utilisateur, les jetons d'authentification, l'état de connexion ou des indices d'appartenance à des salons — indépendamment de l'implémentation réelle du stockage sous-jacent.

Caractéristiques principales

• Stockage au niveau de la session — une instance de store existe par session client connectée

• Sémantique clé-valeur — objets arbitraires associés à des clés de type chaîne

• Indépendant du backend — les implémentations peuvent utiliser la mémoire, Hazelcast, Redis ou d'autres magasins de données

• Conscient du cycle de vie — détruit lorsque le client sous-jacent se déconnecte

• Récupération typée — les valeurs retournées peuvent être castées ou typées génériquement

Comment ça marche

• set associe une valeur à une clé pendant la durée de vie de la session

• get retourne une valeur stockée, ou null si elle n'est pas présente

• has vérifie l'existence d'une clé sans charger la valeur

• del supprime une entrée clé-valeur unique

• destroy supprime toutes les entrées, invalidant l'instance de store

Scénarios d'utilisation

Cas	Exemple
Authentification	store "userId", "tenant", "tokenClaims"
Indices de reconnexion	store "rooms" ou métadonnées personnalisées
Paramètres personnalisés de la poignée de main	conserver des métadonnées utilisateur lors de la mise à niveau/poignée de main
Logique par espace de noms	joindre l'état nécessaire uniquement pendant la session en cours

Avantages

👍 Fonctionne de manière uniforme en mode cluster et autonome 👍 Garde les métadonnées de session isolées pour chaque connexion 👍 Permet de changer le backend de stockage sans modifier le code utilisateur 👍 Prend en charge une opération légère en mémoire pour les déploiements mono-nœud

Limitations

ℹ️ Non destiné aux objets volumineux ou au stockage binaire ℹ️ N'est pas un modèle de données distribué en soi — la distribution dépend de l'implémentation ℹ️ Pas de TTL intégré ni d'expiration au-delà du cycle de vie de la session ℹ️ Non partagé entre les sessions sauf s'il est soutenu par un stockage partagé

---

Comportement du backend

Backend	Persistance	Visibilité	Caractéristiques
En mémoire	Éphémère, effacé à la déconnexion ou au redémarrage de la JVM	Local uniquement	Le plus rapide, idéal pour un seul nœud
Hazelcast / Redis(redis, valkey, dragonflydb)	Distribué (selon la configuration du backend)	Accessible entre les nœuds	Recommandé pour les déploiements multi-nœuds

---

Garantie de cycle de vie

Une instance de Store vit exactement pendant une session client et est détruite lorsque la session se termine. Après avoir appelé destroy(), le store ne doit plus être accédé.

Appelé automatiquement lorsque le client se déconnecte.

Exemple

server.addEventListener("storeDemo", String.class,
        (client, data, ackSender) -> {

    // ----- SET -----
    client.getStore().set("key1", data);
    log.info("SET key1 = {}", data);

    // ----- GET -----
    String value = client.getStore().get("key1");
    log.info("GET key1 = {}", value);

    // ----- HAS -----
    boolean existsBefore = client.getStore().has("key1");
    log.info("HAS key1 (before delete) = {}", existsBefore);

    // ----- DEL -----
    client.getStore().del("key1");
    log.info("DEL key1");

    // ----- HAS again -----
    boolean existsAfter = client.getStore().has("key1");
    log.info("HAS key1 (after delete) = {}", existsAfter);

});