アカウント名:
パスワード:
処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。
対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。
多分、無駄にロックされている所でも有ったのだろ。電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。
無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。
ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。順序だけ合わせたところでデッドロックは回避出来なかったりする。
「簡単だろ。一段FIFOを挟むだけでいいじゃん」これくらいの発想でやってくれないかなw
ＦＩＦＯは、一般のロック制御では有効だけど・・・。
そうではなく、ＲＤＢＭＳのロック制御には、一般的に粒（塊）度の違いがある。行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。
デッドロック回避策は、表ロックで統一する。（お手軽）タスク（ロック）スケジューラを経由してロックを行う。（スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い）
>油断無く間断なく？
筈なんだよな。だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。まさかとは思うが、「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」とか思ってたんじゃないだろうな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
処理が遅延 (スコア:1)
処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。
対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。
Re:処理が遅延 (スコア:0)
多分、無駄にロックされている所でも有ったのだろ。
電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。
よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。
Re: (スコア:0)
無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。
Re:処理が遅延 (スコア:1)
ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。
順序だけ合わせたところでデッドロックは回避出来なかったりする。
Re: (スコア:0)
「簡単だろ。一段FIFOを挟むだけでいいじゃん」
これくらいの発想でやってくれないかなw
Re: (スコア:0)
ＦＩＦＯは、一般のロック制御では有効だけど・・・。
そうではなく、ＲＤＢＭＳのロック制御には、一般的に粒（塊）度の違いがある。
行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。
デッドロック回避策は、表ロックで統一する。（お手軽）
タスク（ロック）スケジューラを経由してロックを行う。（スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い）
Re: (スコア:0)
>油断無く
間断なく？
Re: (スコア:0)
筈なんだよな。
だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。
まさかとは思うが、
「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」
とか思ってたんじゃないだろうな。