「トランザクション管理」の編集履歴（バックアップ）一覧はこちら

「トランザクション管理」(2005/09/10 (土) 15:15:44) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

トランザクションには守るべきACID属性がある。<br>
<table border="1">
<tbody>
<tr>
<th>ACID<br></th>
<th>意味<br></th>
<th>解説<br></th>
</tr>
<tr>
<td>Atomic<br></td>
<td>トランザクションの原子性<br></td>
<td>
トランザクション内の処理はすべて行われたかなにも行われなかったかのどちらかしかない。<br>
</td>
</tr>
<tr>
<td>Consistent<br></td>
<td>データの一貫性<br></td>
<td>
データに一貫性があること。一貫性を守っていない例：親テーブルがないのに子テーブルがある<br>
</td>
</tr>
<tr>
<td>isolated<br></td>
<td>トランザクションの独立性<br></td>
<td>
並行して走るトランザクションが互いに独立していること<br>
</td>
</tr>
<tr>
<td>Durable<br></td>
<td>データの永続性<br></td>
<td>
データが永続化されていること。永続化されているデータが読み出せること<br>
</td>
</tr>
</tbody>
</table>
<br>
<hr size="2" width="100%">
トランザクションの境界<br>
プレゼンテーション層とビジネス層の間に引かれる。<br>
<br>
<ol>
<li>
明示的なトランザクション：ソースコードにそのままかく</li>
<li>
宣言的なトランザクション：フレームワークなどから提供されるトランザクション処理にトランザクション管理を行わせることをいう</li>
</ol>
2を利用することによってビジネス層に含まれるコンポーネントは自由に組み合わせることができ、開発者もトランザクションを意識することなくロジックの記述に専念できる<br>

<br>
アプリケーションアーキテクチャを柔軟なものにするなら２を積極的に使うこと。<br>

<br>
２を使うにはEJBという選択肢もあるがEJBのコンポーネントはEJBコンテナに依存するのでテストがしにくい<br>

<br>
2を利用するならトランザクションの境界となるのはサービスクラスのメソッド。<br>

サービスクラスのメソッドが呼び出されたらトランザクションが開始され、メソッドが終了したらトランザクションがコミットされる<br>

<br>
1を実装しなければいけないなら<br>
プレゼンテーション層でトランザクションを実装し、ビジネス層に含まれるコンポーネントはトランザクションから自由にすべき。<br>

トランザクションが入れ子になってしまうことを気にせず、ビジネス層に実在するコンポーネントを自由に組み合わせることができるから。<br>

またそのときトランザクション管理は1箇所で行うように実装しないとダメ。<br>

たとえばコントローラクラスでサービスクラスのメソッドを呼び出す前後にトランザクションの開始と終了を行うのがよいかもー。<br>

<br>
<br>
<br>
<br>
<br>