WR blog

via Day by day(2005-05-31)

from Data Crunching: Everyday Help (Books)

Data Crunching covers areas of most interest to working programmers:

Using plain text files > Learning how to use Regular Expressions > Parsing XML using SAX, DOM, and XSLT > Encoding data in binary files > Handling relational databases using SQL >

ふむ。面白そう。

「プログラマの最大の武器は、プログラムを書けることである」とは、わいの親方の言葉であり、とても共感する言葉であるけれども、世間一般的な「SE」と呼ばれる立場の人間が日常の業務において「プログラムを書く」機会は少ない。残念ながら。 テキストエディタを相手にする時間よりも、打ち合わせをする時間、Word/Excelに向かう時間、ミドルウェア・OS等のマニュアルを読む時間のほうが圧倒的に多いのが現実。

ただ、「いざ！」というときはやってくる。 たいていの場合、緊急性が求められ、ミスが許されない状況下である場合が多い。

そう、素振り必要。

心の中で思っていても、考えても、「やる環境」を作るところまでやらないと意味がない。 この本がその助けになれば。

June 2nd, 2005 | Category: Book, Programming | Comments (2)

Practical WebObjects 読書会のみ参加。今月はChapter10. WebObjects In A J2EE World。

シンプルなアーキテクチャでServlet対応できてしまうところに、WebObjectsのスジのよさを感じるわけである。

ただ、あいかわらずマルチスレッド関係の処理に不安が残るわけである・・・。 WWDCに行かれる方は、Chales HillさんにEOEditingContextのLock問題について質問してきてください！(どうやらWWDC@SFにて、Pratical WebObjectsの著者がセミナーをやるらしい)

May 28th, 2005 | Category: Event, Java, WebObjects | Comments (1)

エラーの種類を簡単に。

ビジネスロジックエラー(代替フロー) システムエラー 入力エラー プログラミングエラー 内部状態不整合エラー (他にある?)

ビジネスロジックエラー

ユースケースにおける、いわゆる代替フロー。 残高1000円なのに、2000円引き出そうとしたときの処理フローに相当 機能定義・論理設計・基本設計段階で洗い出される必要がある。 機能の一部として、エラー発生時の処理が明確に洗い出されている必要がある。 アプリケーションは、エラー内容に応じた処理を実行するように実装されている必要がある。

システムエラー

動作環境などが正常に動いていない場合のエラー ATMシステムで、ATMとバックエンドシステムのネットワークが疎通していない場合や、バックエンドシステムにおいて、RDBMSが動作していない場合などに相当 基本設計・詳細設計段階で洗い出されている必要がある。 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。 適切に不具合情報を入れ込んだロギングが重要。 2重化など、システムエラーが起こる原因自体を排除するor発生頻度を低める取り組みについては、ここでは触れない。

入力エラー

いわゆるvalidationエラー。入力したデータが、まずい場合 (機能定義・)論理設計・基本設計段階で洗い出される必要がある。 金額入力欄にアルファベットが入力された場合など (ビジネスロジックと同様?)

プログラミングエラー

API・クラスライブラリ・フレームワーク・ユーティリティクラスを適切に使用していないために生じるエラー。 基本的に、詳細設計・プログラミング作業中にしか発生しない。 結合テストにおいてこのエラーの発生する可能性を可能な限り低めるような努力がなされていなくてはならない。 DAOにConnectionをsetせずにfindXXX()メソッドを呼んだ場合など

内部状態エラー

主に2種類あると考える（もっとあるかも）

システムが保持するデータの不整合

マスタ不一致エラーとか 主に運用のミスによる

プログラムのロジックバグにより、満たされているべき前提条件が満たされなくなったため発生するエラー

たいていの場合DAOにConnectionがキチンと設定されるが、特定の処理を実行するとDAOにConnectionが設定されなくなり、nullPointerExceptionが発生する 設計・テスト段階で洗い出しに失敗したプログラミングエラーが顕在化したケースと考えることが出来る。

要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。 適切に不具合情報を入れ込んだロギングが重要。 (システムエラーと同様?)

フェーズとエラー種別とエラーハンドリング

フェーズとエラー種別により、適切なエラーハンドリング戦略は異なる。 プログラミングフェーズで好ましいエラーハンドリングと、保守・運用フェーズで好ましいエラーハンドリングは異なる。そもそも出るエラーの特性がまったく異なるのだから、乱暴な比較ではあるのだけれども。

すくなくとも、エラーハンドリングの目的が、「機能仕様を満たす」ことか、それとも、次のアクションを起こしやすくするための単なる「情報提供」か、で、求められる戦略が異なる点は留意したほうが良い。

ツッコミは愛をこめて。

artonさんの日記のやりとりに刺激されて、妄想含みで書いてみた。乱文失礼。

May 22nd, 2005 | Category: Programming | Leave a comment

from S2.2.9 リリース - koichikのひとりごと

例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合，最初に HSQLDB からコネクションを取得することで，二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます．

なるほどーそういうことか。理解できました！ ありがとうございます！ koichikさん。

昨日の質問

昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。（若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ（苦笑）でした。）

S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、

XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する >

という理解でよいか？

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、 1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

Last Resource Commit Optimization は，このように複数のリソースがある場合に，最後のリソースに対しては prepare ではなく，通常の 1 [...]

May 15th, 2005 | Tags: Transaction, XA | Category: Java, RDBMS, Seasar | Leave a comment