S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

Webサービスっぽくやってみたが…

PL/SQLのプロダクトの中で、CGI(VB)でExcelファイルを生成してるんで、それに倣ってみる。
ところが、DB更新とExcelファイル作成があって、DB更新をServletで、Excelファイル生成をCGIでってした時に、DB更新した内容がCGIで反映されてねぇ?
そりゃトランザクションのスコープが違うから。
ということで、DB更新を取り消す仕組みを作って、DB更新以外で例外が発生した時には自分でロールバックするような感じで対処する。
んなもんで、ざっくり処理はこんな感じ(実際のトランザクション処理はSpring/AOPで実装)。

try {
    // 1)ストアドプロシージャでDB更新(Excelファイル作成の前提処理) ←一旦commit
    // 2)Excelファイル作成(CGI呼び出し) ←CGIで別のトランザクション
    try {
        // [DBMS]begin
        // 3)DB更新                              
        // 4)関連するファイルをSubversionから取得
        // 5)ExcelファイルとSubversionから取得したファイルをZIPファイルにアーカイブ
        // [DBMS]commit
    } catch (Exception e) {
        // [DBMS]rollback
    }
} catch (Exception e) {
    // 6)ストアドプロシージャでDB更新取消(Excelファイル作成の前提処理の取り消し) ←別トランザクション
    throw e;
}
// ZIPファイルをダウンロード

Excelファイルを生成する」という意味で、CGIの役割が理解できる。
Excelファイル作成の前提処理としてのDB更新(手続き)との組み合わせにおいて、別々のトランザクションとして定義し、DB更新とExcelファイル作成を別々に指示することができるUIを用意してやればよさげ?
ただサービスの粒度として適正かどうか?ってのがイマイチ判らん。
これと、ユースケースレベルまたはユースケースのステップレベルとの関係がきれいに整理できるといいのかも。
それと例外/代替フローとの関係とか、前提条件、事後条件との関係とかもありそうだし。


粒度の話は置いといて、ユースケース的に考えてみる。
今回だと
「手続きを登録する」 1)
「手続きに対する帳票を作成する」 2)
「手続きに関係するドキュメントを取得する」 3)〜5)
みたいな感じになる。
実際のUIは、1つボタンアクションで全て処理してる。
これってUIの動きからだとincludeっぽい関係に見えるけど、実はextendじゃね?というのが、上記の「別々に指示することができるUIを用意してやればよさげ?」に繋がるか。
んで、extendの別トランザクションでもOKだけど、includeだと同じトランザクションになるような?せんといかんような?気がする。
そうするとextendな関係だとサービスとして見出せるけど、includeな関係だとダメよとか。
なんかそんなの。
も少し考えてみよ。