> For the complete documentation index, see [llms.txt](https://www.socketio4j.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.socketio4j.org/adapters/adapters-es/introduccion/store.md).

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

});

```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.socketio4j.org/adapters/adapters-es/introduccion/store.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.