なぜオブジェクト指向は賛否両論なのか

オブジェクトの中でsleepしたら、
他のオブジェクトもsleepしちゃう。
プログラムなんてしょせんはプログラムカウンタのリレーなんだから、
そこを無視してオブジェクト指向だとか、他とは独立だとか…。
この業界、オブジェクト指向勉強したら偉いとか思ってるアホがのさばってるんだな。
いやになってきた。

>>719
どんなプログラム書いてんだよｗ
(呼び出し先に)sleepってｗ

あと、何か勘違いしているようだが、オブジェクト指向開発にしようが、
結局呼び出し元のプログラムは単なる関数(サブルーチン)呼び出しと、(自分のモジュールの)データ管理で済むぞ。

>>710
使用目的と状況が分からないので正確には言えないが、ptrA0からptrB1を起動すると言う意味なら設計誤り。
実行順に関する情報は呼び出し元クラスで管理し、呼び出し先クラスでは実行判定メソッドや
実行メソッドを持つ。呼び出し元ではそれらを使用して、実行の制御を行うのが一般的だ。

>>719
オブジェクトの中でスリープしたら、他のオブジェクトもスリープ？
言っている意味が分からない。スレッドやプロセスを使えば止まらないが、そういう意味ではないのかな？
オブジェクト指向に限らず、新しい事を勉強している人は、勉強していない人より偉いんじゃないか？
オブジェクト指向に至っては、知っているのは普通で、知らない人の方が怠慢と言われるレベルだろう。

>>719
>いやになってきた。
とっとと辞めた方がいいと思う。
君、伸びそうにないし。

と駄目なPG>>722に言われた>>719

>>721　おじゃばさまの前に怠慢付けたらどうですか？

>>710
スレッド間メッセージじゃ無いならそんなめんどくさい事しないで、
必要に応じて関数(サブルーチン)を呼び出してくれる制御用のプログラムを作れば良いジャマイカ。

>>695
ほとんど･･･
ということは、おそらく既存ＤＢがガンジガラメでポリシー変えられないんだろう、おそらく。
デッドロックしたらタイムアウトを待つしかないみたいな。

＞オブジェクトの中でsleepしたら、
＞他のオブジェクトもsleepしちゃう。

ＡＰサーバ上に、トランザクションのロック中に関する専用ＤＢ作ってみたら？
ＤＢ1｜ＤＢ１のキー名｜ＤＢ2｜ＤＢ２のキー名｜・・・
Ｔ１　　　　Ｋ１　　　　Ｔ２　　　Ｋ２
常時キャッシュで、終了したら削除、もしくは終了フラグ
その上で、デッドロックを検出したら、特別モード突入みたいな感じで、そいつを待ちキューに入れるとかラウンドロビンさせたり。
ただし、これらはＡＰサーバと非ＡＰサーバとの間のデッドロックの検出は無理だけど。
ＡＰサーバへのリクエストは基本１行更新だよねえ、やっぱ・・、しみじみ思う。

>>725
デッドロックはテーブルのロック順を守れば発生しなくね？
つか更新対象が少々かぶっても(管理者ユーザによるユーザメンテみたいのしょうがなくね？)
楽観排他とかで別に問題なくね？

>>726
オプティミスティック・ペシミスティックというところで、
オプティミスティック使いたい、それが通ればいいけどね。
既存のポリシーでガンジガラメだとそうもいくまい。
それと、まな板サーバみたいなギガキャッシュじゃなくて、メインフレームみたいにキャッシュがテラスゴスみたいな、使う表丸ごと常時キャッシュなところにJAVAサーバ入れられるんなら、
そりゃかなり効率上がると思うよ。
既存でクジラがヒーヒー言いながら動いてるものを、イワシに持ってきたらそりゃミンチになるし。
イワシの大群だといっても、よほど効率よく表が媒体別にパラレルに配置されてないと>ガンジガラメだと難しい
でもいきなりでかいの持ってくるのはコスト的にリスクがあるから。
それと将来イワシが群れなした時、どうにもならなくならないための保険のこのスレのどっか上のほうにあったAPサーバで順序処理だと思うけどね。

>>727
バージョンカラム1つ付けるくらいケチケチすんない
つか、オブジェクト指向なんも関係なくね？

カウンターカラム１個付けるのはいいと思うけど、
既存が分からなきゃ、というか最新を誤るとやばいぞ＞履歴と最新
ということで、カラム追加による既存の修正が必要なんじゃないか

前提としてインクリメントするだけならいいけれど(履歴がないならいいけれど)、
新規用に履歴表を新たに作って(ここにバージョンカラム)既存の表からコピーして(新規側は今までの表と新たな履歴表を両方見て全履歴を判断)、
今までの表はそのまま最新版として既存のやり方で履歴を更新していったほうがいいんじゃないか？
いや考えすぎで蛇足だったらすまんね。

＞つか、オブジェクト指向なんも関係なくね？
まったく関係ないなｗ

>>727
データベースロックの基礎は分かっているのか？
基本的に、トランザクションの途中に入力待ちを入れるのは間違いだし、ロックするのは親となるテーブルの
レコードだぞ。これでほとんどのシステムは問題なく稼働する。
これが使えないのはかなり特殊なシステムだが、そんな特殊なシステムなのか？

>トランザクションの途中に入力待ちを入れるのは間違いだし

もちろんＤＢに対する更新は一発更新だけど、
当然一回のＤＢ更新で複数のレコード追加変更によるデッドロックの懸念や待ち、２フェーズコミット(RPC、J2EEだとRMI/IIOPによる安全終了)のケースもあるからね。
抽出後更新で、既存が楽観排他使ってればいいが、
例えばVTAMなんかオンライン即時更新でクライアントは基本的に１つしか掴まない故に、楽観排他は使って無い可能性もある。
このクライアントのリクエストが別サーバを含める複数レコードロックなんかかましてると。まさかとは思うけどね。

>>729
728は「バージョンを認識出来るカラム（更新日時でも可）を追加して、更新時に最新のレコードと比較して
エラーや警告を出せ」言っているのだろう。履歴と最新？何の事を言っているのか分からないな。

>>730
履歴の処理とロック制御は関係ない話だが、「履歴表を作って既存の表からコピー」？
文面どおりに受け取ると、履歴のためにレコードを別の表にコピーすると聞こえる。
そういう意味なら、DBと言う物が全然分かってないようなので、正規化から勉強し直すように。

>>732
どういう場合を言っているのだ？
トランザクションの途中に入力があって、1つのトランザクションで複数のデータベースを更新する場合か？
それでもロックするテーブルが1つならデットロックしないし、2つでも順番を間違えなければデットロック
しない。1クライアント1ユーザなのに、複数のユーザのレコードをロックするのは設計誤り。
長時間入力があるのにトランザクションの中に入れるのは設計誤り。
問題になるのは、結局はただの設計誤りじゃないか？