08/07/10 02:34:37
>>36
ありがとうございます。
# 不特定多数の場所では用語の使い方には注意しなければいけませんね。今後は気をつけます。
> ドキュメントがあったわけじゃないから、問題が起きないという保証はないですね。
> 本質的に内部状態を持つようなインスタンスじゃないから、大丈夫だと思うけど。
正にその辺りが問題で、イケそうでイケないもどかしさが元となって質問に至った次第です。
「JCEは結局インターフェースの規定であって、SecretKeyについてのマルチスレッド環境下での
動作はドキュメント化されていない。故にその動作は実装依存であり、たとえSUNから提供されているJARが
スレッドセーフであった(ことをリバースコンパイル等の手段を用いて実証した)としても、
仕様化されていない以上、将来のリリースでは変更される可能性がある。」
ということがハッキリしているのであれば、防御的にsynchronizedに倒すという結論に至れるのですが、
現在は、そのための判断の材料を探している段階です。
(SUNからJREと一緒に配布されているJARは、あくまでJCEの規格の一実装という位置づけですよね？)
当然、本当にそこまで仕様に対する厳密な判断が必要なのかという議論も別にあると思います。
また、性能に対してどれだけのペナルティがあるのかによっても、結論は変わると思っています。
# まあ面倒だから同期化にして終了としたい自分もいる訳ですがwww
> SecretKeyとCipherのペアを貸し出し&返却するようなキャッシュ機構
・ペアを幾つか作っておき、貸し出し・返却動作のみを同期処理とする
・ペアが全て貸し出しになった場合のみ、新たなペアを作成して貸し出す
ようなイメージで合ってますか？
確かに、これならば同期、鍵の生成部分は最小限で済むかもしれませんね。
サーブレットのスレッド数とあわせておけば、新たなペアの作成も不要となるような気もします。
ありがたく参考にさせて頂きます。