トランザクション関連書籍

手持ちのトランザクション関連書籍をまとめてみる。なんとなく。

トランザクション処理システム入門

比較的わかりやすい。

トランザクション処理〈上〉―概念と技法

難しい。

トランザクション処理〈下〉―概念と技法

ほとんど読めてない。

OLTPシステム―オンライントランザクション処理

これまた難しい。

.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)

オススメできる。

追記@2005/06/03 ちょっぴり詳しいレビューはこちら

Java Transaction Processing: Design and Implementation (HP PROFESSIONAL BOOKS)

JTAに関連する箇所を拾い読みしただけ。


### PoEAA 4th

* 次回開催までに、なんかしら読めたらいいな&ネタ提供できたらイイなっと。

その他気になる点

* DIコンテナ利用を前提にしたトランザクション処理
* LL(PHP, Perl, … )な人のトランザクション処理
* RDBMS分離性の使い分け

簿記勉強中

10日で合格(うか)る!日商簿記3級最速マスター

ロイホにて勉強。ざーっとなめた。概念はつかめているので、あと2週間で問題を解いて追い込めばよいだろう。

【天使と悪魔のビジネス用語辞典】ウェブ版

【天使と悪魔のビジネス用語辞典】ウェブ版

これは面白い。

通り一遍の説明より、脳みそへの定着度が高い気がするのはなぜだろう?

WOMeeting 2005/05

Practical WebObjects 読書会のみ参加。今月はChapter10. WebObjects In A J2EE World。

Practical Webobjects

シンプルなアーキテクチャでServlet対応できてしまうところに、WebObjectsのスジのよさを感じるわけである。

ただ、あいかわらずマルチスレッド関係の処理に不安が残るわけである・・・。
WWDCに行かれる方は、Chales HillさんにEOEditingContextのLock問題について質問してきてください!(どうやらWWDC@SFにて、Pratical WebObjectsの著者がセミナーをやるらしい)

T字形ER 土曜勉強会

久しぶりに顔を出した。
しばらく休んでいたのに快く迎えてくれた皆さんに感謝!

### As-Is
As-IsとTo-Beを区別することは必要だけど、あまりAs-Isにこだわりすぎるのはどうかと、ふと思った。

XML Schema問題の要約の要約

大ざっぱで当てにならないW3C XML Schema問題の要約

### 過剰な複雑さと基本構造のいびつさ
> W3Cという組織は、自らがXML Schemaを勧告している関係上、建前としてスキーマをXML Schemaで書かねばなりません。その結果、W3Cで行われている多くの言語作成活動においてXML Schemaによるスキーマ作成が行われ、その結果として上手く書けない事例がいくつも発生しているとされています。

XMLのプロフェッショナルであるはずのW3Cに関与する人間すら、XML Schemaを使えていない現実!

### PSVI問題
Post Schema Validation Infoset問題。
同じXML文書でも、XML Schemaを通さなかった場合と、XML Schemaを通した場合でInfosetが変わってきてしまう問題(XML Schemaのデフォルト値の適用)

* 参考 : 『XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く』を読み解いてみたら例示が欲しくなりました – XML & SOA

### 特定される単一のスキーマ
> XML Schemaは、1つの名前空間に対応するスキーマが1つ存在するという前提を取るアーキテクチャであると言われています。

たしかに1つの文書に複数のスキーマを割り当てたいケースもあるかも。
データと妥当性を分離した、妥当かどうかもContextに依存させるような疎結合なアーキテクチャを実現したいケースもありそう。

### 貴族とボヘミアンの対立問題
> XML Schemaは、全てのXML文書に対応するスキーマが存在し、読み込む際には必ず検証を行うアーキテクチャを前提としていると言われます。つまり、検証しない使用法を全て認めないことを理想としていると考えられます。

> ここで注意すべき点は、ボヘミアンの立場がスキーマ不要論ではないことです。スキーマには、使うべき時と、使わない方が良い時がある、という立場です。

現場では、柔軟にXMLを使用したいはず。

### W3Cの権威
>  世界におけるISOにせよ、日本国内におけるJISにせよ、その権威は本来W3Cより高いものであるにも関わらず、WWWの世界ではW3Cが最も権威を持つかのような錯覚が一部にあって、それが盲目的なXML Schema支持につながっている面があります。

W3Cが論理的で理性的な判断を下せない理由は何か?

Contextが提示されていないResultは疑うべきだ

サイボーグ戦士の日記

> よって思ったのはContextが明示されていないResultは
> 逆に全て疑ってかかるべきですね。
> 銀の弾丸は存在しないですから。

日ごろぼんやり思っていることを明快に語ってくれる言葉に出会えることは喜びだ。

* Context+Logic → Result
* What + How → What

なる構造と整理している。

まったく同じContextは存在しない。ゆえに、Resultは役に立たないか・・・というとそんなことはない。
多少Contextが違っても、Logicを抑えておけば、Contextの違いに対応して異なるResultを導き出すことが出来る。

【匠に聞く】モデリングが「道具」になるには専門領域に特化しなければならない──Executable UMLの考案者Stephen J. Mellor氏 : IT Pro ニュース

【匠に聞く】モデリングが「道具」になるには専門領域に特化しなければならない──Executable UMLの考案者Stephen J. Mellor氏 : IT Pro ニュース

via Stephen J. Mellor氏のインタビュー記事 | 日々精進 – スパークスシステムズ ジャパン代表のBlog

> ──UMLは,用途ごとの言語仕様を定義するために「プロファイル」という枠組みを用意している。UMLをベースにしたDSLは,プロファイルとして作られていくことになるのか。
>
>  私個人は,そうならないことを望んでいる。UMLのプロファイルは,あくまでもUMLの範囲内で定義されるものだ。これでは,その業界に存在する独自の記号を利用できない。その業界で長年積み上げられてきた資産が切り捨てられてしまう。これはとてもばかげた話だ。その業界に適した記号を使った表記法にすべきだ。

Mellor氏はDSL派のようだ。

PoEAA 3rd

PoEAA読書会 第3回に参加した。まとまりなく書いてみる。

* 発表資料はこちら

### 駆け込みで前夜に資料作成
前夜1:00am-6:00amぐらいで3章のサマリをPPTで作成し、持参&発表。
直前に駆け込みで作ったこともあり、内容はイマイチだったけど、議論のベースとして機能したので結果オーライ。ということにする。んで、質は量に転化する。ということにする。(これまでも、これからも)

あ、資料作成の際には昔WOMeetingで使った資料を流用したりした。継承の実装方式の図や、RDBMSのイメージとかEnterpriseObject(笑)とか。ちょっと手を抜けた。

### 進め方など
当初、15?25分程度でさくっと進めるつもりだったのだけど、実際始めてみると、
発表しつつ、議論しつつな感じで進めたほうがよさそうな印象を受けたので、そうすることにした。
自分が2部以降をキチンと読み込んでいなかったため、議論についていけなかったり、議論の整理がうまくなかったりした部分があったのは反省点。でも、読み込む時間がないのよねー。あと、情報を体系化して、脳みそへ定着するための時間が。

議論に参加してくれた方、感謝。いろいろ話して、楽しくやりましょう。
特に、ひがさんには感謝!感謝!有益なネタ振りをたくさんしてくれた。しかも、カナリ読み込んでるし!
つーか、発表者のくせしてあまり読み込んでなくてごめんなさい。たたき台として存在する意味があると自分に言い聞かせる。

### UnitOfWork
EOEditingContext! EOF最強! 楽○○○○○○御が実質的に機能しない点を除いては!(苦笑)

### 外部キー制約、参照整合性
外部キー制約付けない派が大多数。なるほど。確かに実務上は付けないほうがよさそうではあるのだけど。
ちょっと意外ではあった。

### 依存
依存概念をCASCADE ON XXX制約でカバーできるかどうか?については良くわからない。
EOFの場合、(確か) 親Objectと子Objectのリレーションシップを切断すると、子Objectが削除されたはず。
というわけで、Objectの世界で依存概念の意味をどこまで規定するかに依存すると思われる。
ただ、たいていの場合、CASCADE ON XXX制約で十分な気がしている。

一瞬、ER図にも依存概念を導入したほうが良いかなと妄想した。うーん、IDEF1xとかだと入ってそうだな。でも、あれを理解する気にはなれない・・・。ま、いいや。

### EOF/WebObjects
発表が終わって、ogijunさんとボソボソ。
やっぱ、EOFはいけてるねーとか。

O/Rマッパーに必要な概念のほとんどを実装しているからねぇ。
Apple買収後も、XML対応とかいろいろ適切な方向に進化してくれたら面白かったのに!とか思う。

あと、Webフレームワークがステートフルな方向に行くのなら、WebObjectsフレームワークも・・・って、完全に脱線だなコリャ。

ちょっとWebobjectsに興味をもたれたかたは、ここらへんとか、suzukiさんの有益な資料(spice-of-life.net – WebObjects)などをごらんくださいまし。

### 概念をビジュアル化することの効能
余談だけど、概念を脳みそへ定着させるために発表スライドをつくるというのは結構有益。
ソフトウェアをビジュアル化する作業は、モデリング技術の延長上にある。複雑なもの・見えないものをある側面に着目して、表現することに相当する。短期的・長期的に有益。
というわけで、誰か、次回のサマリ担当に立候補してくれないかなーと。

* ポジションペーパ

### リンク集発見!
ありがとうございます。koicさん。

* Day by day(2005-05-23)

Russian Doll と Salami Slice

スキーマ設計とクラス図 | ノート

なるほど。興味深い。

同じことを書くのに、ちょっと自由度があるのがイヤンなかんじもするな。