|
|||||
|
手持ちのトランザクション関連書籍をまとめてみる。なんとなく。 比較的わかりやすい。 難しい。 ほとんど読めてない。 OLTPシステム―オンライントランザクション処理 これまた難しい。 オススメできる。 追記@2005/06/03 ちょっぴり詳しいレビューはこちら JTAに関連する箇所を拾い読みしただけ。 ### PoEAA 4th * 次回開催までに、なんかしら読めたらいいな＆ネタ提供できたらイイなっと。 その他気になる点 * DIコンテナ利用を前提にしたトランザクション処理 * LL(PHP, Perl, … )な人のトランザクション処理 * RDBMS分離性の使い分け […] ロイホにて勉強。ざーっとなめた。概念はつかめているので、あと2週間で問題を解いて追い込めばよいだろう。 サイボーグ戦士の日記 > よって思ったのはContextが明示されていないResultは > 逆に全て疑ってかかるべきですね。 > 銀の弾丸は存在しないですから。 日ごろぼんやり思っていることを明快に語ってくれる言葉に出会えることは喜びだ。 * Context+Logic → Result * What + How → What なる構造と整理している。 まったく同じContextは存在しない。ゆえに、Resultは役に立たないか・・・というとそんなことはない。 多少Contextが違っても、Logicを抑えておけば、Contextの違いに対応して異なるResultを導き出すことが出来る。 * リアルタイム・システムの構造化分析 リアルタイム・システムの仕様書作成手法 – 電脳書房在庫目録 昔から読んでみたく思っていたのだけど、いまさら・・・・って感じだな。高いし。 なぜ読みたいと思っていたのか？というと、分析のためのツールキットはたくさん持っていたほうがよいと考えるから。 コンサルタントが経営分析などのテンプレートをたくさん用意しているように、 設計者・分析者はソフトウェアの分析のためのある程度のツールキットを用意すべきと考えるから。 さて、土曜日までにどこまで読めるかなー 職場で設計に関する議論があり、自分がJavaのメモリモデルを理解していないことを痛感させられた。 というわけで、 * Javaの理論と実戦: Javaメモリ・モデルを修正する 第1回 * dW : Java technology : Javaの理論と実戦: Javaメモリ・モデルを修正する 第2回 * Java言語規定 スレッド及びロック などを読んで学習。メインメモリとローカルメモリの同期をとることが肝要と理解した。 Java言語仕様は、メモリモデルと呼ばれる、いわゆるRAM、キャッシュ、レジスタなどなどから構成される実際のマシンのメモリを適切に抽象化したモデルを用い、そのモデルがどのような要件を満たさねばらないか？を規定している。あくまでもモデルに対する要件のみを規定しているため、実際のマシンアーキテクチャから、比較的独立性を確保することができる。という仕組みになっているようだ。誰が考えたか知らないが、うまい仕組みだ。モデルの適切な定義・モデルの適切な利用と感じられる。 さて、この作業を通じて改めて思うのは、Whatを正しく知るためにはHowを知らなくてはならないということである。ある概念を、自然言語や類似の概念でいくら説明されても、詳細は理解できない。「それがどうやって実現されるか」を知らなくては、概念をキチンと理解できないのだ。 この例でいうと、プログラミング言語がどのような機能性を果たしているかを説明するためには、プロミング言語の処理がどのように実行されるかを知らなくてはならないということになる。 ただ、このWhatとHowの関係で注意していただきたいのは、Howを説明するときに使用する下位の概念の抽象度・詳細度である。 Howはある下位の概念を用いて記述されなければならず、かつ、問題を説明するのに適切なレベルで詳細な概念を用いて説明しなくてはならない。Howを説明する際に用いた概念が詳細すぎては、Howが複雑になりすぎて、Whatを理解することが難しいことは容易に理解できるだろう。 What -> How -> What -> … 無限ループ・・・。 オチはない。 Amazonマーケットプレイスで安価に販売していたので衝動買い。 実は昔から気にはなっていたのだけど、プラットフォームが.netだったので買うのを躊躇していた。 内容はかなりイイ。.netに関係しなくても、トランザクション設計について悩みがある人は、立ち読みして内容を試し読みするぐらいの価値はありそう。私に関しては、少なくとも値段分の元は取れそうな感じである。 .netフレームワークでエンタープライズアプリケーション開発をする人は必読ではないだろうかね。カナリお勧めできます。 以下に、この本の良い点をあげる。 まず第一に、アプリケーション開発者の立場で書かれている点がある。 ACIDなどのトランザクションそのものの概念や、RDBにおけるトランザクションを論じた・解説した書籍は数あれど、アプリケーション＋RDB or/and … で構成されるシステム全体においてトランザクション設計をどのように行うか？を論じた本は少ない。和書だと皆無に近いのではないだろうか？この本は、その領域をターゲットとしている。 第二に、トランザクション、同時実行制御、ロック、分離性など、初学者が混同しがちな概念を整理して語っている点。 私は、SQL Serverにおいて、分離性を変えることでどのようにロックの保持期間が変わるか？取得するロックの種類が変わるか？の説明が面白く感じた。(2.2 分離レベルによるロック挙動の変化） 恥ずかしながら、分離性の概念がどのように実現されているかをキチンと理解していなかったため、この箇所を興味深く読ませていただいた。ロック保持に関する概念図とEnteprise Managerのロック状態表示画面を多用して丁寧に解説されているため、非常に理解しやすくなっている。すばらしすぎます。 第三に、わかりやすさを優先しつつも、正しさにも配慮している点。 本書では、おそらくわかりやすさのため、多少の厳密さを犠牲にした記述がされている。 本文で犠牲にした厳密さを補うため、筆者の愛情こもった脚注がたくさん記してある。これまた、すばらしい。 第四に、「くーす」に近いステートレスなクラス設計を説いている点（笑）。 まぁ、COM+の流れから当然なんですが、MSの立ち位置は「ビジネスロジックはステートレス」というもの。 筆者は、これを踏まえつついくつかの補足的な説明をしており、その結論として、 「エンティティ中心のオブジェクト指向設計は、スタンドアロンのシングルユーザアプリケーションに向いているケースが多いが、WebアプリケーションやWebサービスのような、サーバサイドのOLTP型マルチユーザアプリケーションには適していない。」と整理している。まったく持ってそのとおりと感じている。 第五に、具体的なアプリケーション毎に、設計方針を示している点。 対話型アプリケーション、バッチアプリケーション、キュー型のアプリケーションなどのに対して ある程度具体的な指針を示している。（ただし、本書の中で著者が述べているとおり、「定式化が難しい」ため、さすがに「この記述に従えばうまくいく！」という内容までにはなってない。というか、なりえないよね・・・。） ロイホにしけこみ読書。 Essential XML・・・うーむどうなんだろう。ちょっと必要以上にわかりにくく書いてないか？この本。 訳が良くないというのもあるけど・・・（シリアライズを「順序化」って、あーた・・・。せめて「直列化」で頼む。） インフォセットの語りもなんだか抽象的でよーわからんし、SAX、DOMのあたりも構成が練れていない感じ。 PoEAA読書会に向けて、2部のパターン、O-Rマッピングあたりをさらりと読む。 1部の概論はイマイチしっくり来なかったが、2部はまぁまぁな気がする。 各パターンの説明の中で、未説明のパターンに言及するあたりがなんだかなーだけど、 各パターンの概要が頭に入ってきてパターン間の関係を頭の中で整理することができると、 比較的すんなり読めた。 ただ、ファウラーのコメントが散文的で踏み込みが甘いので、若干フラストレーションがたまるなぁ。 もう少し、具体的なコメントがほしいところではある。 現在は様々なフレームワークが出回っているわけだから、それらに触れるような切り口もありなのでは？と思ったりした。 ### EOFとPoEAA ### パターンの本来的な役割は、共通の語彙・概念の形成であると理解している。 というわけで、PoEAAの語彙・概念を利用してEOFを表現する。（乱文すぎるので、たぶん、あとで書き直す） ### ドメインロジックパターン ### ドメインロジック(=ビジネスロジック) の割り当ての方針は、基本的に「ドメインモデルパターン」が推奨される。 もちろん、画面にビジネスロジックを埋め込むような実装・設計も可能ではあるけれども。 物理的にも、「ドメインモデル」を実装したオブジェクト群をパッケージ化・フレームワーク化して、様々なアプリケーション形態（WOFと呼ばれるリッチなWebアプリケーションフレームワークを使用したWebアプリケーション、DirectToWebと呼ばれるルールベースのUI定義ベースのWebアプリケーション、Javaクライアントなどなど）で、それらを共用することが(それなりに)一般的であるようだ。 ### データソースのアーキテクチャに関するパターン データソースとオブジェクトの変換は、オブジェクトグラフとリレーショナルモデルの変換という形で実行される。 であるので、「データマッパーパターン」になるのかな？ オブジェクトとリレーショナルの対応は、物理的には*.eomodelファイル群、論理的にはEOModelGroup、EOModelなどのメタモデルクラス群で管理される。（「メタデータマッピングパターン」に相当） ### オブジェクトリレーショナル振る舞いパターン ### 基本的に、「ユニット・オブ・ワーク パターン」。 EOEditingContextと呼ばれる、オブジェクトグラフの編集用ブール、SandBox的なオブジェクトが存在しており、これがオブジェクトグラフの編集状態を管理する。編集をコミットしたタイミングで、オブジェクトの編集処理が、SQLクエリに変換される（「データ・マッパー パターン」）。この際、デフォルトでオプティミスティックロック戦略が使用される・・・ことになっている。(苦笑&謎めき) EOEditingContextの寿命とWeb層のSessionの寿命がシンクしている点がなかなかいい感じではある。 (超私見) #### 一意マッピング #### 異なる2つの世界、RDBMSとオブジェクトの中で、一意性をどのように、どのレベルで確保するか？という戦略。 EOFは一意性に関しては、2種類の一意性管理をもつ。 「ユニット・オブ・ワーク」単位の一意性と、データベース群レベルの一意性であり、EOGlobalIDなるクラスを用いることで一意性管理を実行する。EOGlobalIDは「データソース×テーブル×プライマリキーの組み合わせ」と考えてよい。文字通り、複数データソース内で、グローバルに一意である。 1つの編集用領域(EOEditingContext)には、同じEOGlobalIDのオブジェクトは1つしか読み込まれない。 ただし、複数ユーザーが編集中である場合など、複数の編集用領域が存在する場合、同じEOGlobaIDのオブジェクトが複数存在する。(当たり前！) ただし、下位のデータ管理レイヤがそれぞれのオブジェクトをトラッキングしており、あるオブジェクトが編集された場合、同じEOGlobalIDを持つ別のオブジェクトに変更を伝播させたり、しなかったりする。 #### レイジーロード #### レイジーロードはfaultingと呼ばれる機構でサポートされる。 関連の先にぶら下がっているオブジェクトは、必要に応じてRDBMSから読み込まれる。 […] [結] 石井さんの訃報 – 結城浩の日記 とあるML経由で事実を知った。 直接お会いしたことはないのだけど、自身がxUnitを実践する際に非常に参考にさせていただいた。実際、自身のプロジェクトでも、テスト対象のオブジェクトにtoString()メソッドを持たせるテクニック、expectedとactualのdiffをとるテクニックなど、実際に活用させていただいたアイディアがある。 Agile界に、pragmaticな方法論を提供したという意味で、皆に幸せを与えた方だと思う。 心よりご冥福をお祈り申し上げます。 会社の定時後、出張の前に駅前の書店へ行き購入した。 勉強会は、これを持参して望む予定。よろ！ |
|||||
|
Copyright © 2024 WR blog - All Rights Reserved Powered by WordPress & Atahualpa |
|||||
