-ThreadLocal全滅？

java

http://weblogs.java.net/blog/jfarcand/archive/2006/01/introduction_to.html

  1. If the request is completed, but keep-alived, release the thread and register the SelectionKey for IO event
  2. if the request isn't completed, release the thread but keep the ReadTask attached to the SelectionKey, to keep the connection state/history.
  3. if the request is completed and not keep-alived, release the thread and the SelectionKey.

This strategy prevent one thread per request, and enable Grizzly to server more that 10 000 concurrent users with only 30 threads.

前後の事情も込みで意訳

  1. リクエストが完了しても、keep-alivedだったら、スレッドは解放してIOイベントキューにNIOソケットをぶち込みます（ちょっとNIOのSelectionKey周辺の説明を乱暴に省略してます。こう訳しちゃうと本当はちょっと正しくない）。
  2. リクエストが完了してなければ、スレッドを解放してGrizzlyのReadTaskをNIOソケットと結びつけます。コネクションの状態と履歴を保持するためです。（たぶん特にはcomet対応かなと思ふ。ここにJetty6とかだとcontinuationによるコールスタックの冬眠テクニックが登場してくるのかな？）
  3. リクエストが完了してかつ、keep-alivedではなかったら、スレッドもNIOソケットも解放

上記のように（とにかくスレッドをすぐ解放しちゃうGrizzlyアーキテクチャでは）リクエスト毎に1スレッド必要なんてことはなく、Grizzlyによってたった30スレッドで10,000の同時接続ユーザをさばけるようになるんですよ。（すごいでしょう。）

でだ、これはこれですばらしくいいんですが、Grizzly（つまりはnon blockingサーバソケット）によるThread消費効率の問題解決を行った場合、ThreadLocalを使ってるフレームワーク群はどうなっちゃうんだろう？結構まずいんじゃないかな？多分。ThreadLocalはJSFでもS2でもMayaaでも最近のフレームワークでは結構広域にいろんなところで使われているので痛いことになるんじゃないかと、ふと心配してみるテスト。ちょっと検証が必要。一方で実装してみたらProcessorTaskのトランザクション空間内でごにょごにょやるだけであったというのであれば大丈夫な気もするが。。。


追記：
http://d.hatena.ne.jp/masataka_k/20061201/1164940929
大丈夫でしょうね。