良いエントリにはてなスターがつくとは限らない
http://d.hatena.ne.jp/nowokay/20081119#1227076215
と
http://d.hatena.ne.jp/nowokay/20081120#1227153604
を見て思った。ブックマークがずっとつかなくて心配していたけど。
※注 なんかリンク先間違えた気がするけど気にしなーい
トランザクショナルメモリで必ず思い出すのが楽観的ロックでループ処理をしていなくて競合したときに不具合がでるというやつ。バージョンカラムがないてるぜ。
ちなみにこれ、ソフトウェアのみでやろうとするとデータのコピーがかなり問題になる。今回の例のように単純なものならいいけど、実際はそんな簡単にいかない。ディープコピーの問題がすぐに発覚するし、単純にデータのコピーによる時間が問題になる。となると、変更箇所のみバージョンを持つという考え方が必須になってJavaのみではどうにもならない。
実際のアプリでは書き込みが少ない場合メリットが最大になるわけだが、そもそも書き込みが少ないのならライトロックしていてもそんなに問題にならなかったりする。
トランザクションが非常に少なく、そのたまに実行されるトランザクションが異様に長い場合のみに威力を発揮するわけだが、それがどれだけあるだろうか。
バージョン管理機能をもつRDBを普通に使ったほうが結局無難だということになったりする。
ちなみにjava.util.concurrent.atomicは便利そうに見えて一般的なアプリでは使う場面がまずない。一意となる連番が欲しい場合はRDBのシーケンスを使うことになるだろう。マシンが正常稼動している間のみ動く連番処理が欲しい場面は結構少ないのだ。複数のマシンを導入して負荷分散をするならばなおさら。
Javaのconcurrentパッケージでよく使うのは
- Executors
- ExecutorService
- CountDownLatch
- CyclicBarrier
- BlockingQueue
- ThreadPoolExecutor
これくらいかな。Thread＋独自ライブラリで管理していたときに比べたら組込Javaのプログラミングは天国だと思う。Queueインターフェースが定義されたのも大きいかな。
Queueの話が出たのでついでに話すと、非常に便利そうなPriorityQueueは意外と使い物にならない。同じ優先度の場合の処理をカスタマイズできないから結局自前で作ることになる。
話があっちこっちにとんだりしてるが気にしなーい。
