10月25日（火）1、2コマ目

今日の予習

C#＋OracleDB

今までもC#からOracleDBにアクセスするプログラムを作ってきましたが、エラーが発生した時点で例外を呼び出し元にスローしていました。

エラー発生時の例外スローをコントロールするプログラムに改造しまします。

古典的な書き方

try{ }catch{ }をつかう書き方。Javaと同じ。


usingステートメントを使う

Javaのtry with resourcesと同じようなusingステートメントを使う書き方。


コミット・ロールバック

Javaと異なるのが、Transactionオブジェクトがあるところ。このTransactionオブジェクトでコミット、ロールバックを行う。


今日、やったこと

[課題]Java+トランザクション

今日のホワイトボード

[課題]Java＋トランザクション

StockDAOクラス


サーブレット


JSP


C#+OracleDB

ソースコードは上の「今日の予習」をご参考に。

メソッドのオーバーライド

Javaの場合は特になにも指定しなくてもメソッドのオーバーライドができたが、C#では明示的にoverrideを指定する必要がある。

図　オーバーライド

Javaの@Overrideアノテーションは指定しなくてもOK。指定した場合は、オーバーライドするつもりがスペルミスでオーバーライドしていない（引数が違う、メソッド名が違う）ようなときにコンパイル時に警告してくれます。


Transactionオブジェクト

C#ではJavaにはないTransactionオブジェクトがあり、これを使ってトランザクションコントロールをします。

Transactionオブジェクトは接続済みConnectionオブジェクトのBeginTransaction()メソッドで取得できます。

TransactionオブジェクトはCommandオブジェクトのTransactionプロパティにセットします。同じTransactionオブジェクトがセットされたCommandオブジェクトは同じトランザクションのメンバになります。

コミットはTransactionオブジェクトのCommit()メソッド実行、ロールバックはRollback()実行です。

図　トランザクション

次回は

C#＋トランザクションの練習問題です。


このブログの人気の投稿

11月14日（月）1、2コマ目

イメージ
今日、やったこと 例外（C#) 今日のホワイトボード 処理終了時の状態 処理終了時は 正常終了 異常終了 の２つに分かれます。 さらに、異常終了も 想定内のエラー 想定外のエラー の２つに分かれます。 エラーを「想定内」、「想定外」 分けていますが、「想定外」なエラーもよく考えれば「想定内」なエラーになります。 ここで、エラーの内容を以下のように再定義します。 「想定 内 のエラー」は 利用者にエラー発生を伝えて、リカバリをしてほしい エラー。 「想定 外 のエラー」は 利用者に通知してもしょうがない エラー。 図　想定内のエラー、想定外のエラー 処理結果をどうやって伝える 処理(メソッド)の結果は 〇ユーザーに通知してリカバリしてほしいエラー 　 戻り値で通知 〇ユーザーに伝えてもしょうがないエラー 　 例外スローで通知 図　結果を伝える方法 ただし、 この方針は絶対的なものではありません 。 しかし、この授業では今後この方針でいきます。 戻り値は 結果が 成功 失敗 の2種類ならbool型へ。 処理結果の状態が3つ以上なら列挙型(enum型)で。 図　戻り値のつかいわけ 例外スロー時の対応 やってはいけない ことは 　 例外をキャッチしてもなにもしない(catchブロック内が空) です。 基本的に、例外がスローされたら そこで処理は中断 呼び出し元へエラー発生を通知（例外スロー） ...
続きを読む

10月27日（木）3、4コマ目

今日、やったこと [練習問題]C#＋コミット・ロールバック  今日のソースコード 正解例をあげておきます。 Startup.cs セッションなし。いつもどおり。 Item.cs プロパティ＋コンストラクタのクラス。いつもどおり。 ItemDAO.cs Update()メソッドがポイントでしょうか。 Index.cshtml.cs OnPost()メソッドがポイントでしょうか。 基本的な流れは以前Javaでやった同じ仕様の練習問題と同じです。 Index.cshtml とくにややこしいことはないかと思います。 次回は 今日の練習問題の解説とロックの練習問題です。
続きを読む

10月4日（火）1、2コマ目

イメージ
今日、やったこと トランザクション 今日のホワイトボード トランザクションとは 1件の処理＝１トランザクション。 たとえば、送金処理とか在庫更新とかで１つのトランザクション。 １つのトランザクションには複数のSQLを実行するケースが多い。 トランザクションに必要な要件 ACID特性が必要。 Atomicity（原子性） Consistency（一貫性） Isolation（独立性） Durability（永続性） トランザクションの原子性 トランザクション終了時には 全ての更新を実行 まったく更新をしていない のいずれかでなければならない。成功した更新と失敗した更新が存在するのはNG。 図　トランザクション終了時の状態 トランザクションの原子性はコミット、ロールバックで実現。 図　コミット、ロールバック トランザクションの独立性 トランザクションは単独で実行しても、複数同時に実行しても結果は同じでなければならない。 図　複数トランザクションが同時に実行されると そのために、トランザクション同士を分離、独立させて実行し、互いに影響が及ばないようにする。 このトランザクションの分離レベルが全く分離しない（Read Uncommitted)からほぼ完ぺきに分離する（Serializable）まで4段階ある。 この分離レベルに応じて、他トランザクションにいろいろな影響（ダーティーリード、ファジーリード、ファントムリード）が発生する。 ダーティーリード 他トランザクションで、更新したがコミットしていないデータを参照してしまうこと。 図　ダーティーリード 多くのDBの分離レベルはRead Committedなので、ダーティーリードは発生しない。 Read Committedなら、非コミットデータは参照しない。 ファジーリード 同じデータを参照しても、他トランザクションが更新することで、毎回異なるデータを参照すること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファジーリードが発生する。 ファントムリード 他トランザクションが追加、削除することで、参照するたびに出力行数が異なること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファントムリードが発生する。 ロック DB更新時には更新対象行をロックして、...
続きを読む