OO エンジニアの輪 ～ 第 26 回 鷲崎 弘宜さんの巻 ～ | オブジェクトの広場
パターンの良さ・難しさ -- パターンを考える時って、もの凄く時間と労力が掛かると思うので、最初の敷居が凄く高い感じがするのかもしれないですね。 しかし、それがパターンランゲージの良さだと思います。 ソフトウェアパターン・パターンランゲージの与える良さには 2 つあって、 1 つは記述形式がもたらすのスムーズな意思疎通。単なる問題解決対ではなく、解決に至る過程などが伝わりやすいということです。 もう 1 つは、考えなければ、解決に至った理由が書けない事ですね。 私はうんうんうなることが大事だと思います。 「このソフトウェア構成はどういう理由で得られて、どういう理由で使うんだ。」と考える機会って結構少ないんですよね。 パターンは「なぜそういう解決策を取るのか？」「なぜそういう解法に至ったのか？」という理由と過程を真剣に考えるきっかけを与えてくれます。 -- 一般的に、最初にパターンのどの部分
分散トランザクションに挑戦しよう！
では、複数のデータベースに対してアクセスする場合、どのようにすれば原子性を保証できるのでしょうか。これを解決するのが、図 2 に示す 2 フェーズコミットと呼ばれる方法です。 2 フェーズコミットでは、図 2 のようにトランザクションのコミット処理を 2 段階のフェーズにわけることによって原子性を保証します。ちなみに図 2 の UML 表記は、厳密ではありません。どのようなメッセージが交換されるのかについてのみ注目してください。 第 1 フェーズでは、まず、各データベースに対してコミットできる状態であるかどうかを確認するための準備 ( 図 2 の prepare ) の指示を送ります。これを受けた各データベースは、コミットできる状態かどうかをアプリケーションに伝えます。この処理を「投票する」と呼びます。コミットができる状態であれば、コミット予定の内容を確定させた後、アプリケーションに対して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
