次の目標で LDAP キャッシュを作成したいと思います
LDAP サーバーへの接続試行を減らす
エントリが存在し、キャッシュ内で有効な場合は、ローカル キャッシュを読み取ります
以前にそのようなリクエストがない場合、またはキャッシュ内のエントリが無効な場合は、ldap から取得します
現在、バインドされていない LDAP SDK を使用して LDAP をクエリしていますが、動作します。
いくつかの調査を行った後、機能する可能性のある永続的な検索の例を見つけました。LDAP サーバーの更新されたエントリはエントリを searchEntryReturned に渡し、キャッシュの更新が可能になります。
しかし、非同期であるため、これを行う方法がわかりませんか、キャッシュに実装するより良い方法がありますか? 例とアイデアは大歓迎です。
LDAP サーバーは Apache DS であり、永続的な検索をサポートしています。
プログラムは JSF2 アプリケーションです。
Apache DS は、RFC 4533 で定義されているコンテンツ同期コントロールの使用をサポートしていると思います。これらのコントロールは、システム間の一種のレプリケーションまたはデータ同期を実装するために使用される場合があり、キャッシングはその用途としてやや一般的です。UnboundID LDAP SDK は、これらのコントロールをサポートしています (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html)。これらのコントロールと RFC 4533 に含まれる情報を調べて、それがより適切かどうかを判断することをお勧めします。
別の方法として、Apache DS が LDAP 変更ログをサポートしているかどうかを確認することもできます (たとえば、draft-good-ldap-changelog で説明されている形式で)。これにより、変更されたエントリに関する情報を取得して、ローカル コピーで更新できるようになります。変更ログを定期的にポーリングして新しい変更を探すことにより、自分のペースで変更に関する情報を使用できます (アプリケーションがオフラインの間に行われた可能性のあるものを含む)。
あなたのケースでは永続的な検索が機能する可能性がありますが、問題を引き起こす可能性のあるいくつかの問題があります。1 つ目は、更新されたエントリがクライアントに送信される速度を制御できないことです。クライアントが変更を消費するよりもサーバーが変更をより速く適用できる場合、これはクライアントを圧倒する可能性があります (これは観察されています)。多くの実際のケースで)。2 つ目は、永続的な検索では、どのエントリが更新されたかはわかりますが、どのような変更が加えられたかはわかりません。キャッシュの場合、エントリ全体のコピーを置き換えるだけなので大きな影響はないかもしれませんが、それ以外の場合はあまり望ましくありません。もう 1 つの大きな問題は、永続的な検索では、検索がアクティブな間に更新されたエントリに関する情報しか返されないことです。
多くの理由から、クライアント側のキャッシュは一般的に悪いことです。古いデータをアプリケーションに提供する可能性があり、誤った動作を引き起こしたり、場合によってはセキュリティ リスクを引き起こしたりする可能性があり、認証に使用している場合は絶対に大きなセキュリティ リスクになります。また、すべてのクライアントがキャッシュに含まれるデータに対して同じレベルのアクセス権を持っているとは限らない場合、セキュリティ上のリスクが生じる可能性があります。さらに、クライアント アプリケーションごとにキャッシュを実装することはスケーラブルなソリューションではありません。複数のアプリケーション間でキャッシュを共有しようとする場合は、それを完全なディレクトリ サーバー インスタンスにすることもできます。追加のキャッシュを必要とせずに、必要な負荷を簡単に処理できるサーバーを使用する方がはるかに優れています。