コンバージョン後のエラーについて
Unipaas V1 Plusより magicxpa4.9へコンバージョン作業を行った後に
magicxpaの環境で
トランザクションモード (物理)
トランザクション開始 (レコード更新前) でトランザクションがオープン
できませんと数百本のエラーが発生しています。
トランザクション開始を (なし)にするのが正解とマニュアルに書かれていました。
質問は
プルダウンメニューから コード WP0266を警告から無視にするとエラーは
でなくなります。この状態でプログラムを実行しても特に問題はなさそうなので
すが、やはりトランザクション開始を (なし)に全て変更しなくてはいけない
のでしょうか。
お手数ですが宜しくお願いいたします。
-
Ｙ・Ｎさん、こんにちは
WP0266は、XPAの確か3.Xからだったと思いますが、論理的な矛盾のチェックで追加されたと記憶しています。
本来物理transactionの開始タスクでは、それ以下のタスクを含めて使用するテーブルをすべてオープンしておく必要があります。（異常時に開始時点までロールバックさせるのが目的ですから）
以前のバージョンですと、それをしなくてもｴﾗｰも警告も出なかったのですが、SQLのログで見るとtransactionは開始していないので、何かあればテーブル間のデータ値に不整合が発生します。
ですので、WP0266が出た場合、transactionの開始と終了を見直しして、異常時にどこまでロールバックさせたいのかを再確認する機会だと思いますよ。（数が多いと、大変ですが、、、、💦）
HAYATO@アインシュタイン設計社
-
ありがとうございます。
問題を避けるために全て修正します。
以前に
サーバー windows2016server データベース microsoft SQL2017 Server
ソフト Unipaas V1 Plus
この環境内で運用中にシステムが遅延してしまい動かなくなってしまうと言う問題を
質問しましたが改善策が見つからず、プログラム修正で減少は少なくなったものの発生はしています。
トランザクションモード (物理) トランザクション開始 (なし)
を行う事により、改善は見込めるでしょうか。
-
Ｙ・Ｎさん、こんにちは
＞トランザクションモード (物理) トランザクション開始 (なし)
＞を行う事により、改善は見込めるでしょうか。
-----------------------------------------------------------------------------
遅延が起きた時の状況がデッドロックならば、そうだと思います。
ただ、むやみにtransactionを無効化するのも、考え物です。
今まで、それで整合性を保てていたかもしれませんしね
デッドロックの問題でしたら以下の新しいフラグを試してみては如何でしょうか？
SpecialRecordCriticalLockWait
レコードのクリティカルロックを防止 このフラグは、レコードのクリティカルロックが発生した場合に、
無限ループの発生を防止するために使用されます。このフラグは、 Magic xpaがロック情報の取得後にスリープ状態にする時間（ ミリ秒数）を指定します。これにより、 OSがコンテキストの切り替えを実行できるようになります。 有効な値：数値 デフォルト:0 設定例： SpecialRecordCriticalLockWait= 100 SpecialTableCriticalLockWait
テーブルのクリティカルロックを防止 このフラグは、テーブルのクリティカルロックが発生した場合に、
無限ループの発生を防止するために使用されます。このフラグは、 Magic xpaがロック情報の取得後にスリープ状態にする時間（ミリ秒） を指定します。これにより、 OSがコンテキストの切り替えを実行できるようになります。 有効な値：数値 デフォルト：0 設定例： SpecialTableCriticalLockWait= 100 HAYATO@アインシュタイン設計社
-
スレ主ではありませんが遠藤勇人様 情報ありがとうございます。
どちらも存在を知りませんでした。
拠点別 年月別 商品在庫データなどをデッドロックさせるなどしてしまう作りのPGがあったりするのですが、SpecialRecordCriticalLockWaitを設定するといい事があるのでしょうね。
サインインしてコメントを残してください。
コメント
4件のコメント