[seasar-dotnet:2148] Re: S2Dao.NetでORA-01002が稀に発生する現象について(再送)

kotani.k [E-MAIL ADDRESS DELETED]
2012年 4月 11日 (水) 23:35:33 JST


大森さん

小谷です。

トランザクション開始〜コミットの流れは問題なさそうですね。
他に気になる点としましては・・・

・VMが3機あってそれぞれがDBサーバとのことですが、
 1回の処理でA,B,CそれぞれのDBを更新しているでしょうか?
 (ログを拝読する限りではデータソース「001」しか使われていないようですが念のため)
 (複数のデータソースを使用している場合、トランザクションはデータソースごとに
 別々に発行されます。そのこととマテリアライズドビューによる同期が
 何か問題を起こしている可能性を想定しています)

・各DB用のTransactionSettingで行っている拡張は「TypicalTransactionSetting」を
 DataSourceNameプロパティだけoverride、のような形でしょうか?
 それともSetupTransactionメソッドなど他のメソッドも拡張されているでしょうか?
(ログに"トランザクションを開始しました"、"トランザクションをコミットしました"というログが
 一回のトランザクションで二つずつ出ているようなのですが、
 こちらのテスト環境では一つずつしか出力されなかったため、そちらの方も気になりました)


また、こちらも更に更に念のための確認になるのでお時間があれば、の話になるのですが、

・S2Container.NET 1.3.18を使った場合でも問題は再現するでしょうか?
(1.4.0-RC2との機能的な違いはないので関係ないと思われますが、
 1.4.0-RC2は.NET Framework4.0上での使用を想定して作成しています。
 .NET Framework3.5上でお使いなのであれば1.3.18の方が安定しているかと思います)

・自動コミットの設定はどのようになっているでしょうか?
 (既定値を使用している場合、既定値はONかOFFか)

あまりお力になれず、申し訳ないです。
以上、よろしくお願いします。

2012年4月9日15:44 K.Ohmori <[E-MAIL ADDRESS DELETED]>:
> 小谷さん
>
> 大森です。レスポンスいただきありがとうございました。
> その後、確認と検証を行いました。
>
>
>> ・即時エラーを返すNO WAITではなく通常のSELECT 〜 FOR UPDATE、またはWAIT 秒数を指定してみる
>
> ⇒通常のFOR UPDATEは顧客からの要件として採択できないのですが
>   WAIT秒数指定は同じ結果だろうという推定で済ませてましたので
>   テスト登録を繰り返し実行してみましたが現象をおこせませんでした。
>   あわせてNO WAITでもテスト登録を繰り返し実行してみましたが現象をおこせていません。
>
>
>> ・SELECT〜FOR UPDATE NO WAITが本当にロックをかけたい行のみ該当する条件になっているか確認する
>> ・ストアドプロシージャ内にロックが解放されない分岐がないか見直す
>
> ⇒こちらについては今一度再確認しましたが、見落としはありませんでした。
>   大まかな実装の流れはVBにてトランザクション開始 ⇒ 対象データロック ⇒ トラン追加 ⇒
>   ストアド呼出 ⇒ ストアド実行結果に応じてコミット or ロールバック、としています。
>
>> ・commit/rollbackのタイミングを見直す
>
> ⇒こちらについてはAOPで制御しています。AOPを使用しないで制御する、といった認識でよろしいでしょうか。
>
> 他に考えられる検証・見直しポイントはなにかありますでしょうかね・・
>
>
> 以上です。
>
>
>
>> 大森さん
>>
>> 小谷です。
>>
>> 私もGMailですが前の投稿も今回の投稿も正常に閲覧できております。
>>
>> >○画面を閉じずに登録を繰り返している時に発生している模様
>> >○1回目の更新実行時にはまず発生しない
>> > ⇒現象発生時に画面を閉じて(DB切断している)、起動し直して
>> >  登録を実行すると正常更新できる
>>
>> とのことですので前の更新でかけられていたロックが解放されないうちに
>> SELECT 〜 FOR UPDATE NO WAITで次のロックをかけようとしてしまい
>> 発生しているように思えます。
>>
>> ・即時エラーを返すNO WAITではなく通常のSELECT 〜 FOR UPDATE、またはWAIT 秒数を指定してみる
>> ・SELECT〜FOR UPDATE NO WAITが本当にロックをかけたい行のみ該当する条件になっているか確認する
>> ・ストアドプロシージャ内にロックが解放されない分岐がないか見直す
>> ・commit/rollbackのタイミングを見直す
>>
>> などを試した場合どうなるでしょうか?
>> (既に確認済の事柄でしたらごめんなさい)
>>
>> 以上です。
>>
>> 2012年4月3日21:10 kubo <[E-MAIL ADDRESS DELETED]>:
>> jfluteです。
>>
>>> 当方が昨日投稿しました記事を保存書庫スレッドにて拝見したところ
>>> タイトルのみ正常で本文がすべて文字化けをおこしておりました。
>>> MLメンバーの皆さまには大変ご迷惑をおかけしました。
>>
>>
>> 一応、報告まで。
>> 自分、GMailですが以前の投稿も正常に閲覧できていました。
>>
>> 2012/4/3 K.Ohmori <[E-MAIL ADDRESS DELETED]>:
>>>
>>> 大森と申します。
>>>
>>> 当方が昨日投稿しました記事を保存書庫スレッドにて拝見したところ
>>> タイトルのみ正常で本文がすべて文字化けをおこしておりました。
>>> MLメンバーの皆さまには大変ご迷惑をおかけしました。
>>>
>>> 当方にて利用しているメーラーでの投稿ですと、文字コードの問題が
>>> あるようですので、再三で申し訳ありませんが投稿記事を
>>> 別のメーラーから再送させていただきます。
>>>
>>>
>>>
>>> 現在従事しているプロジェクトで稼働中のシステムの
>>> 更新処理(Quillでのトランザクション処理)にて下記の現象が発生していまして、
>>> なかなか収束できず苦しんでおります。
>>>
>>> どこがまずいのか指摘点があれば教えていただけないでしょうか。
>>> もしくは同様あるいは類似した現象の解決事例をお持ちの方が
>>> いらっしゃいましたら、どうかご教授ください。
>>>
>>>
>>> [事象]
>>> ○VB.netの画面からの更新処理を実行する際の
>>>  トランザクション処理部にて、対象データのロックを
>>>  行っているが、ロックに失敗して
>>>  「ORA-01002:フェッチ順序が無効です。」が発生する
>>> ○一貫した再現性がなく、稀にしか発生しない
>>> ○画面を閉じずに登録を繰り返している時に発生している模様
>>> ○1回目の更新実行時にはまず発生しない
>>>  ⇒現象発生時に画面を閉じて(DB切断している)、起動し直して
>>>  登録を実行すると正常更新できる
>>> ○1度発生すると、入力内容を保持して更新処理を再実行しても
>>>  再度失敗することがある。失敗を繰り返す時は10分以上続くこともある。
>>>
>>>
>>> [システム環境]
>>> ○サーバーOS:Windows2008 R2 (64Bit)
>>>  ⇒VM Ware ESX Server上で稼動する仮想OSです
>>>  ⇒VMは3つあり、サーバAに共用DBを上位に位置させ、
>>>  その下位にサーバBとC(事業所別のDB)が同位で位置します。
>>> ○DB:Oracle 11g R2 11.2.0.1.0(64Bit)
>>>  ⇒VM3機A、B、CそれぞれがDBサーバであり、サーバ間の連携は
>>>  マスタ:マテリアライズドビューでDB同期
>>>  トラン:テキスト連携(SQL loaderで取込)
>>> ○クライアントOS:Windows 7
>>>  ⇒F社のデスクトップ機です
>>>  ⇒サーバA、B、Cの物理筐体がある拠点と、クライアントの拠点は
>>>  NTTのVPNワイドにてWAN接続されています
>>> ○開発言語:VB.NET (Framework 3.5)
>>> ○開発環境:Visual Studio 2008
>>> ○S2Container.net:1.4.0 RC2
>>> ○ODP.NET サーバー側64bit 11.2.0.0、クライアント側32bit 11.2.0.2
>>>
>>>
>>> [補足]
>>> ○トランザクション処理での更新対象テーブルが複数ある
>>> ○トランザクション処理の冒頭、UPDATEやINSERT発行前にロックしている
>>> ○ロックはSELECT 〜 FOR UPDATE NO WAITで発行
>>> ○トランザクション処理を実装しているサービス実装クラスのメソッドには「<Transaction()>
>>>
>>> _」を指定
>>> ⇒VMのDBが分かれていますので各DB用にTransactionSetting拡張しています。
>>> ○サービス実装クラスのメソッドには「Public Overridable Function」を指定
>>> ○トランザクション処理を実装しているメソッド内で、DAOに定義した
>>>  メソッド(※)を呼び出している
>>>  ※「<Procedure("hogehoge")> _」を指定しPL/SQLパッケージ(ストアード・
>>>    プロシージャ)をコールしている
>>> ○PL/SQL内はトランザクション処理は宣言していない
>>> ○CURSOR検索中にコミットは行っていません
>>> ○接続プール関連の指定はすべて未指定=既定値。
>>>  (Connection PoolやMAX Pool Size、LifeTimeなど)
>>> ○登録実行時のメソッドの流れは下記の通り
>>>  1)formのF10キーに割当した登録ボタンを押下
>>>  2)formのボタンClickイベントプロシージャ呼出
>>>  3)2)内で更新処理(formメソッド)を呼出
>>>  4)サービスインタフェースの更新処理(「<Implementation()> _」指定)のメソッド呼出
>>>    ⇒実体はサービス実装クラスの更新処理(「<Transaction()> _」指定)のメソッド
>>>
>>>
>>>  5)4)のメソッド内の冒頭で、更新処理前にロックしている
>>>  6)トラン1〜3の更新
>>>  7)トラン4の更新
>>>  8)5)でロックしているトラン5の更新
>>> ○アプリケーションログを添付します
>>> [正常系]hoge_seijou.log
>>>  1)3行目:トランザクション処理開始
>>>  2)6~17行目:更新対象データをロック
>>>  3)18〜24行目:トラン1をINSERT
>>>  4)25〜31行目:トラン2をINSERT
>>>  5)32〜39行目:トラン3をINSERT
>>>  6)40〜56行目:データ抽出
>>>  7)58行目:PL/SQL呼出(トラン4を更新⇒トリガ連動⇒別テーブルデータを更新)
>>>  8)78行目:PL/SQL呼出(トラン5を更新)
>>>  9)79・80行目:更新(コミット)正常完了
>>> [異常系]hoge_ijou.log
>>>  1)3行目:トランザクション処理開始
>>>  2)6~17行目:更新対象データをロック
>>>  3)20行目:「ORA-01002: フェッチ順序が無効です」が発生
>>>
>>> 以上よろしくお願いいたします。
>
>
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet


seasar-dotnet メーリングリストの案内