Almacén

El Almacén La interfaz define una abstracción de almacenamiento clave-valor por sesión para socketio4j. Permite a transportes, espacios de nombres y código de usuario persistir pequeños fragmentos de metadatos con alcance de sesión, como IDs de usuario, tokens de autenticación, estado de conexión o indicios de pertenencia a salas—independientemente de la implementación real del almacenamiento subyacente.

Características clave

• Almacenamiento con alcance de sesión — existe una instancia de almacén por cada sesión de cliente conectada

• Semántica clave-valor — objetos arbitrarios asociados a claves de tipo cadena

• Independiente del backend — las implementaciones pueden usar memoria, Hazelcast, Redis u otros almacenes de datos

• Consciente del ciclo de vida — destruido cuando el cliente subyacente se desconecta

• Recuperación con tipado — los valores devueltos pueden ser casteados o tipados genéricamente

Cómo funciona

• set asocia un valor con una clave durante la vida de la sesión

• get devuelve un valor almacenado, o null si no está presente

• has comprueba la existencia de una clave sin cargar el valor

• del elimina una única entrada clave-valor

• destroy elimina todas las entradas, invalidando la instancia del almacén

Escenarios de uso

Caso	Ejemplo
Autenticación	almacenar "userId", "tenant", "tokenClaims"
Pistas de reconexión	almacenar "rooms" o metadatos personalizados
Parámetros personalizados del handshake	persistir metadatos del usuario desde upgrade/handshake
Lógica por espacio de nombres	adjuntar estado necesario sólo durante la sesión actual

Ventajas

👍 Funciona de forma uniforme en modos cluster y en modo independiente 👍 Mantiene los metadatos de sesión aislados por conexión 👍 Permite cambiar el backend de almacenamiento sin cambios en el código del usuario 👍 Soporta operación ligera en memoria para despliegues de nodo único

Limitaciones

ℹ️ No está pensado para objetos grandes ni para almacenamiento binario ℹ️ No es un modelo de datos distribuido por sí mismo — la distribución depende de la implementación ℹ️ No tiene TTL o expiración incorporada más allá del ciclo de vida de la sesión ℹ️ No se comparte entre sesiones a menos que esté respaldado por un almacenamiento compartido

---

Comportamiento del backend

Backend	Persistencia	Visibilidad	Características
En memoria	Efímero, limpiado al desconectarse o al reiniciar la JVM	Sólo local	El más rápido, ideal para un solo nodo
Hazelcast / Redis(redis, valkey, dragonflydb)	Distribuido (según configuración del backend)	Accesible entre nodos	Recomendado para despliegues multinodo

---

Garantía de ciclo de vida

Una instancia de Store vive exactamente durante una sesión de cliente y se destruye cuando la sesión termina. Después de llamar a destroy(), no se debe acceder al almacén nuevamente.

Se llama automáticamente cuando el cliente se desconecta.

Ejemplo

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);

});