アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
ちょっと意外ですが (スコア:2, 参考になる)
今まで無かった? ちょっとびっくり。
oracleで云うところの,FOR UPDATEでOpenして,fetch loop内側で
CURRENT OF...でUPDATEって事が出来る様になったって事かしらん。
って,調べてみたら,英語のリリースノートにそのまま載ってました・・・。
http://developer.postgresql.org/pgdocs/postgres/release-8-3.html
E.1.3.6. Queries
こいつは,プログラマにとっては嬉しい機能ではないでしょうか。
Re: (スコア:0)
「典型的Webアプリプログラマ(特にそれしか知らない奴)にとっては」
何のことか判らないかも。
典型的Webアプリでは
SELECT FOR UPDATEのようにデータを捕まえておくってことは
避けるベキとされているようなので。
表示画面でのSELECT(のためのDBセッション)と
次の更新画面でのUPDATEとを
いかに「べつべつに切り離す」か?が重要である、
とされているようなので。
でも、
大量の顧客を右から左に捌く外向きサービスなら
確かにそれが真なんだけど、
べつに全てのWebアプリがそういうものとは限らなくて、
(「限れ」と強制する権利は多分誰にも無い)
掴んでいることのデメリ
Re: (スコア:0)
本当にそう思うか?
いつロールバックするつもりなんだ?
ステートレスセッションが基本であるはずのwebシステムにおいて、
状態を維持することが目的のトランザクションがなじまないのは、
少し考えればすぐわかるだろう。
そもそも、httpみたいな本質的にステーフルになじまない構造と、
コネクション維持が可能でステーフルに馴染むクラサバを同一視してるあたりが、
理解不足ではないだろうか?
Re:ちょっと意外ですが (スコア:0)
多くの(全てとは言わないが)の「Webアプリ」では、
HTTPのステートレスっぷりをむき出しのまま使ってるわけじゃなく、
ラッパーでステートフルに見せてますね。
それによって、上位層から見れば差は無いことになります。
(期間数十分…数日という)タイムアウトという概念が有る点が違うだけで。
(というか大抵の通信にゃ
遥か下位の層にステートレスな層が有るはず。
それをラップしてタイムアウトつきステートフル通信に見せてる。
その層の位置が高いか低いかの違いだけ。)
現実で具体的に何をしているかというと、
クラサバでは本物のクライアントがクライアントパソコン上に居ますが、
Webあたりだと「仮想的なクライアント」は実はサーバ上に居ます。
その仮想クライアントをWebブラウザでリモコンしてることになります。
ある意味でVT端末だのX端末だのVNCだのと似てる(面も有る)わけです。
ただまあ現実的には、
●サーバに何万人ものユーザが押し寄せたときに耐えられるスケーラビリティ
●HTMLベース(特に非Ajaxならば)のUIの貧弱さ
を思うと、
仮想クライアント内のデータ(Model)※をリクエスト毎に捨てるという構成の
メリットのほうが大きくなることがある(多い)のは事実ではあります。
つまり「ステートレスセッションだから」というのとは「別の」理由により
典型的Webアプリはああいう構成になってる、ということです。
ならば、その条件があてはまらない(レアだけど無理ではない)状況では、
別に定番に従う必要も無い、のです。
(逆にいえばクラサバだって同時ユーザ数増やすなら覚悟が必要です)
※「Model部分に」リクエストごとにデータを忘れる仕組みを
設けてあるFWもあります。
Apache Wicketはそうなっているようです。興味深いFWです。
最近日本でのユーザ会が立ち上がったようなのでどうぞ。
>いつロールバックするつもりなんだ?
クラサバだってTransactionをダラダラ持ちっぱなしにしてたら
怒られるときゃ怒られます。
「長時間掴んでたら不味いんだからxx秒後に例外あげてロールバックする」
という仕組みを入れておけばいい
(場合によっては、おかないとだめ)です。
#結局Webアプリも、1ユーザ(?)あたり複数個のスレッドを与えたい場面は結構有ろう。
#もちろんスレッドは使いまわせばいいから、同時ユーザ数*Nってわけではないが。