アカウント名:
パスワード:
処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。
対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。
次のトラブルは決まったな。整合性とれなくなって「DBが破壊された」
人類には並列処理はまだ早すぎるんだ。
ナメック星にいけばなんとかなる!
互換性がない(出来ることもあれば出来ないこともある)ので、結局、スタッフをヘッドハンティングしてDBの作り直しだろ。でんで話にならないな。
次は三木谷さんがスタッフをヘッドロックでお願いしたい
>でんで話にならないな。
???「ボクだっていろいろ工夫して頑張ってるんですよ!」
>「どんな願いも」から「可能な限り」と口上も少し変化している。この新しい神龍で叶えられる願いの数は2つだったが、その後魔人ブウ編においては叶えられる願いの数が3つに強化され、多くの人を生き返らせた場合、叶えられる願いは2つに減少する。願いを叶えた後は姿を消し、ドラゴンボールはドラゴンレーダーにも反応しない石ころとなって世界中に散らばり、基本は1年間願いを叶えられない条件だが、魔人ブウ編において、3つの願いのうち1つ叶えただけなら4ヶ月後に再び神龍を呼び出すことができるという特例も示された
最長老にできてデンデにできないことあったかなと考えてみて、最長老は潜在能力を引き出す事ができたなと思い出す。データベースの潜在能力を引き出せないデンデはやっぱりだめか?
精神と時の部屋(サーバールーム)にこもって修行(修正)すればいいのでは?
多分、無駄にロックされている所でも有ったのだろ。電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。
無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。
ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。順序だけ合わせたところでデッドロックは回避出来なかったりする。
「簡単だろ。一段FIFOを挟むだけでいいじゃん」これくらいの発想でやってくれないかなw
FIFOは、一般のロック制御では有効だけど・・・。
そうではなく、RDBMSのロック制御には、一般的に粒(塊)度の違いがある。行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。
デッドロック回避策は、表ロックで統一する。(お手軽)タスク(ロック)スケジューラを経由してロックを行う。(スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い)
>油断無く間断なく?
筈なんだよな。だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。まさかとは思うが、「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」とか思ってたんじゃないだろうな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
処理が遅延 (スコア:1)
処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。
対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。
Re: (スコア:0)
次のトラブルは決まったな。整合性とれなくなって「DBが破壊された」
Re: (スコア:0)
人類には並列処理はまだ早すぎるんだ。
Re: (スコア:0)
ナメック星にいけばなんとかなる!
Re: (スコア:0)
互換性がない(出来ることもあれば出来ないこともある)ので、
結局、スタッフをヘッドハンティングしてDBの作り直しだろ。でんで話にならないな。
Re: (スコア:0)
次は三木谷さんがスタッフをヘッドロックでお願いしたい
Re: (スコア:0)
>でんで話にならないな。
???「ボクだっていろいろ工夫して頑張ってるんですよ!」
>「どんな願いも」から「可能な限り」と口上も少し変化している。この新しい神龍で叶えられる願いの数は2つだったが、その後魔人ブウ編においては叶えられる願いの数が3つに強化され、多くの人を生き返らせた場合、叶えられる願いは2つに減少する。願いを叶えた後は姿を消し、ドラゴンボールはドラゴンレーダーにも反応しない石ころとなって世界中に散らばり、基本は1年間願いを叶えられない条件だが、魔人ブウ編において、3つの願いのうち1つ叶えただけなら4ヶ月後に再び神龍を呼び出すことができるという特例も示された
Re: (スコア:0)
最長老にできてデンデにできないことあったかなと考えてみて、最長老は潜在能力を引き出す事ができたなと思い出す。データベースの潜在能力を引き出せないデンデはやっぱりだめか?
Re: (スコア:0)
精神と時の部屋(サーバールーム)にこもって修行(修正)すればいいのでは?
Re: (スコア:0)
多分、無駄にロックされている所でも有ったのだろ。
電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。
よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。
Re: (スコア:0)
無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。
Re:処理が遅延 (スコア:1)
ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。
順序だけ合わせたところでデッドロックは回避出来なかったりする。
Re: (スコア:0)
「簡単だろ。一段FIFOを挟むだけでいいじゃん」
これくらいの発想でやってくれないかなw
Re: (スコア:0)
FIFOは、一般のロック制御では有効だけど・・・。
そうではなく、RDBMSのロック制御には、一般的に粒(塊)度の違いがある。
行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。
デッドロック回避策は、表ロックで統一する。(お手軽)
タスク(ロック)スケジューラを経由してロックを行う。(スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い)
Re: (スコア:0)
>油断無く
間断なく?
Re: (スコア:0)
筈なんだよな。
だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。
まさかとは思うが、
「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」
とか思ってたんじゃないだろうな。