PofEAA 読書会(第4回) - Concurrency

遅ればせながら報告と感想をまとめておきます。(7/3)


場所の予約を担当した関係で少し早めに会場へ到着。
部屋の鍵を開けて冷房を入れて準備OK... のはずが人数が多かったため隣の部屋へ移動、冷房があまり効いていなくてゴメンなさい。
集合場所へ行ってみると角谷さんがなぜかマスクをしている。おや? と思いつつその場では聞かなかったが、やはり具合が悪かったんですね。ポジションペーパーの発表のあとご早退。ごくろうさまでした。

第5章 並行性(Currency)

荻野さんの発表。「軽ロック」「緩ロック」などの訳語が話題になるかと思ったが、英語版を元にされていたため、素直に Optimistic Lock、Coarse Grained Lock、etc. で話が進み、その分中身の議論に集中できた。

5.2 実行コンテキスト

日本語版 P.68 の、

エンタープライズアプリケーションで使用されるサーバソフトウェアは、リクエストとセッションの両方を、クライアントからサーバへという角度と、クライアントを別のシステムへという角度から見る。

はどういう意味かとの質問があって、いくつか意見が出たような気がしたが結局よくわからなかった。

5.4.1 一貫性のない読み込みの防止

Optimistic な方法で一貫性のない読み込みを防止するには、システム全体のバージョン番号(日本語訳の「共有データのバージョン」)を振ればよいとのこと(by ひがさん)。勉強になった。

5.4.2 トランザクション可能なリソース

共有ロックでロックする行数が増えると、リソースの関係で表ロックに移行する(ロックエスカレーション)ので注意!!

5.5.3 即応性に対するトランザクション分離性の制限

分離レベルの話は以前仕事で調べたことがあったので議論についていけた。ただ、読書会でも話題になったが Fowler の説明はかなり分かりにくかったと思う。
まず説明の順番は、Serializable → Read Uncommitted ではなく、Read Uncommitted → Serializable の方が良かったと思う。
あと例題はファイルの例でも良いが、Read Committed と Read Uncommitted の説明はファイル数ではなくファイルの内容で説明した方が一貫性があったと思う。

5.5.4 ビジネストランザクションとシステムトランザクション

日本語版 P.79 の、

ドメインモデルを使用している場合は、ユニットオブワークによって(ビジネストランザクションの)変更を正確に記録できる。

の部分、前回 UnitOfWork は Hibernate の Session だとの説明があったが、Hibernate の Session はここまで賢くはない。

5.7 アプリケーション

「ここでのセッションは HttpSession ではないのでは?」と、koichikさんから意見があったが内容を忘れてしまった。(^^;)

複雑なトランザクション制御

WRさんの発表。第5章の復習になった。前回に引き続いてこれだけの資料を作るパワーには感服します。

2次会

kdmsnrさん、ちくわさん、WRさん、koichikさんとお話をさせていただいた。
kdmsnrさんは「ぶりきじゃ」でお世話になっている。僕の日記もときどき見てくださっているとのこと、ありがとうございます。
ちくわさんに RubyOnRailsOnZaurus を見せていただいた。いつもとても嬉しそうで心が和みます。
koichikさんの話はブログそのものでした。すみません、ついていけませんでした。(^^;)
でも、読書会での議論や seasar ML での対応を拝見すると、技術的にも人間的にも尊敬できそう。次回ももう少しお話してみようと思う。
そうそう、てっきり年下かと思ったら年上なんですね。わかいっす。