ストア

その ストア インターフェースは socketio4j のセッションごとのキー・バリュー格納抽象を定義します。 トランスポート、ネームスペース、およびユーザーコードが、実際のバックエンドストレージ実装に依存せずに、ユーザーID、認証トークン、接続状態、ルーム所属のヒントなどのセッションスコープの小さなメタデータを永続化できるようにします。

主な特徴

• セッションスコープのストレージ — 接続されたクライアントセッションごとに1つのストアインスタンスが存在する

• キー・バリューの意味論 — 文字列キーに関連付けられた任意のオブジェクト

• バックエンド非依存 — 実装はメモリ、Hazelcast、Redis、その他のデータストアを使用できる

• ライフサイクル対応 — 基盤となるクライアントが切断されると破棄される

• 型安全な取得 — 返される値はキャストまたはジェネリクスで型指定できる

動作概要

• set セッションのライフタイムにわたってキーに値を関連付ける

• get 格納された値を返す、または null 存在しない場合

• has 値を読み込まずにキーの存在を確認する

• del 単一のキー・バリューエントリを削除する

• destroy すべてのエントリを削除し、ストアインスタンスを無効化する

利用シナリオ

ケース	例
認証	ストア "userId", "tenant", "tokenClaims"
再接続のヒント	ストア "rooms" またはカスタムメタデータ
カスタムハンドシェイクパラメータ	アップグレード／ハンドシェイクからユーザーメタデータを永続化する
ネームスペース別ロジック	現在のセッション中のみ必要な状態をアタッチする

利点

👍 クラスタモードと単体モードの両方で一貫して動作する 👍 セッションメタデータを各接続ごとに分離して保持する 👍 ユーザーコードの変更なしにストレージバックエンドを切り替え可能 👍 単一ノード展開向けに軽量なインメモリ動作をサポートする

制限事項

ℹ️ 大きなオブジェクトやバイナリの保存を目的としない ℹ️ それ自体が分散データモデルではない — 分散は実装に依存する ℹ️ セッションライフサイクルを超えた組み込みのTTLや有効期限はない ℹ️ 共有ストレージでバックされていない限りセッション間で共有されない

---

バックエンドの挙動

バックエンド	永続性	可視性	特性
インメモリ	一時的、切断またはJVM再起動時にクリアされる	ローカルのみ	最速、単一ノード向けに最適
Hazelcast / Redis(redis, valkey, dragonflydb)	分散（バックエンドの設定に依存）	ノード間でアクセス可能	マルチノード展開に推奨

---

ライフサイクル保証

Store インスタンスはちょうど1つのクライアントセッションの間存在し、セッション終了時に破棄されます。 呼び出し後 destroy()、ストアに再アクセスしてはならない。

クライアントの切断時に自動的に呼び出されます。

例

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

});