ソフトウェア工学実習 2022年度後期(2年)

今日、やったこと [練習問題]C#+ロック 今日のホワイトボード 複数のSQLを同一トランザクションのメンバにするには 同じトランザクションオブジェクトを参照するコマンドオブジェクトは同じトランザクションのメンバになります。 図　複数のSQLを同一トランザクションのメンバにする ロック用SQLの実行 C#にはJavaのexecute()メソッドに相当する超ユーティリティメソッドがないため、ExecuteScalar()で代用してください。 図　ロック用SQLを実行する 今日のソースコード Startup.cs いつもどおり。セッションオブジェクトは使いません。 Item.cs いつもどおり。ID、商品名、在庫数のプロパティとコンストラクタ。 ItemDAO.cs Update()メソッドがポイント。 ロック用OracleCommandオブジェクトと更新用OracleCommandオブジェクトの両方に同じTransactionオブジェクトをセットすること。  Index.cshtml.cs OnPost()の引数は押されたボタンのvalue属性値(商品ID)のみ。 ボタンからIDを取得、引き当て数入力用テキストボックスのname属性を生成する。 Index.cshtml 特にややこしいことはないかと。 次回は C#+トランザクションの確認テストをやります。 確認テストの注意点 今回の課題は前回Javaで作ってもらったものと同じようなものです。 前回のJavaの提出物には無駄な結合をしている人がちょこちょこおられました。今回は注意してください。 図　無駄な結合

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

今日の予習 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()実行です。 図　トランザクション...

今日、やったこと [練習問題]Java＋トランザクション　ロック編  今日のソースコード 作成してもらった練習問題のソースコードです。 ItemDAO.java update()メソッドで 更新対象行をロック 更新実行 の順でSQLを実行しています。２つのSQLは成功ならコミット、１つでも失敗ならロールバック実行です。コミット、ロールバック実行でロックも解除されます。 IndexSrv.java サーブレットです。 doPost()で 押されたボタンはどの商品？ どの商品の割り当て数入力値を取得すればいい？ がポイントでしょうか。 index.jsp とくにややこしいことはないかと。 次回は 今日、配布した課題の締め切りは 　10月25日（火）1コマ目終了時 です。

今日、やったこと Java+トランザクションの練習問題　ロック編 今日のホワイトボード 実装にあたり なにげに一番ややこしそうなところが「どの商品の引当ボタンがクリックされたか」、「どの商品の引当数を取得するか」です。 ヒントをあげておきました。 図　ヒント また、「引当ボタンが押された商品の引当数には必ず数量が入力されている」を前提にして構いません。 次回は 実装＋解説です。 

今日、やったこと Java＋トランザクション　Web版練習問題 今日のソースコード 作成してもらった練習問題のソースコードです。 ItemDAO.java とくに難しいことはないと思いますが、ポイントはupdate()メソッドでしょうか。 IndexSrv.java doPost()メソッド内の全商品の価格入力値の取得部分がポイントです。 index.jsp とくに難しいことはないかと思います。 あと、商品情報を受け渡すためのItemクラスも作成しました。 今日のホワイトボード Java、C#のメソッド命名規則 コンパイルエラーにはなりませんが、暗黙のルールレベルで守られています。 何気に、この手のルールを守る、守れないでスキルがばれます。侮れません。 図　Java、C#のメソッド命名規則 プロジェクトの中 パッケージ構成とjspの配置場所についてです。 図　パッケージ構成とjspの配置場所 今後、jspはWEB-INFの中に置きます。 WEB-INF以下はクライアントが直接アクセスできないため、サーブレットでjspへフォワードして表示することになります。 図　index.jspはWEB-INF以下に ページ遷移 Java、C#問わず、Webアプリケーションのページ遷移にはリダイレクトとフォワードの2種類が用意されています。 リダイレクト HTTPのステータスコード300番台の機能を使ったページ遷移です。ステータスコード300番台はホームページがサーバーを変更した際に、変更先サーバーを伝えるために利用されています。 リダイレクト先はWebであればどこでもOKです。 図　リダイレクト フォワード JavaやC#のアプリケーション内でページ遷移を処理するやり方です。 フォワード先は基本的に同じアプリケーション内と思ってください。 図　フォワード 次回は 更新前にロックするアプリケーションを作ってもらいます。

今日、やったこと Java＋トランザクションの練習問題 今日のホワイトボード 例外をスローするメソッドの呼び出し DAOクラスのメソッドはSQLExceptionをスローするケースが多いです。そんなメソッドを呼び出す際は ・例外をキャッチする ・例外をさらに上位にスローする のどちらをする必要があります。 サーブレットのdoGet()やdoPost()は ServletExceptionとIOExceptionをスローすると宣言しており、これ以上検査例外（SQLExceptionは検査例外）を上位にスローすることができません。 よって、SQLExceptionをキャッチする必要があります。 キャッチしてなにもしないのはマズいので、今回はServletExceptionに変えてスローし直しています。 図　サーブレットにてSQLExceptionをスローするメソッドを呼び出す 次回は 1コマは今回の続き（練習問題作製時間）。 残りは解説。

今日、 やったこと Javaでトランザクション実装（コミット、ロールバック） Javaでトランザクション実装（手動ロック） 今日のホワイトボード JDBCで更新 JDBCは更新系SQLを実行するたびにコミットされるのがデフォルト。 図　JDBCのデフォルトはSQL実行ごとにコミット実行 複数のSQLで1トランザクションを構成する場合は、この自動コミット機能をオフにする必要がある。 また、コミット、ロールバックもしかるべき箇所で実行するように実装しなければならない。 図　自動コミットオフ、コミット・ロールバック実装 古典期なDBアクセス手法で実装 複数の商品データをすべて更新できればコミット、１つでも更新失敗すればロールバックする。 実装例 try-with-resourcesを使って実装 try-with-resourcesを使えば、コネクションの解放（DB接続切断）はtryブロック終了時に自動的にやってくれる。 図　try-with-resources DBによっては、　 DB切断時に非コミットデータは自動的にロールバックする 。よって、明示的にロールバックしなくてもいい。 しかし、オラクルは　 DB切断時に非コミットデータは自動的にコミットする 　ので注意。 図　非コミットデータの扱い 実装例 手動でロックする 更新系SQLを実行する際、DBは更新対象行をロックする。 ただ、場合によっては複数行をまとめてロックしたいとか、ロックして値を確認後更新したいケ...

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