1001コメント284KB

国産DIコンテナSeasar その15

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2009/03/17(火) 20:48:19

0097デフォルトの名無しさん

2009/05/22(金) 16:31:06

Java も Ruby も両方使ってるけど、
>>95 はなにも Rails をわかっていない。
Rails の本質は、別にフルスタック型フレームワークであることだけではない。
Rails もおもしろいから、やってみるといいよ。

>>96
Merb をご存じということは Ruby の web フレームワークはご存じのようだが、
Seasar が話題を集めたのは、

・DI コンテナに Spring もあるけど、当時の Spring は XML をいっぱい書かなければならず、面倒だった
・Seasar はそのへん楽に設定できたし、ドキュメントも日本語だし、そもそも国産ということで話題になった
・S2Dao (今は S2JDBC もあるけど)の 2way SQL がけっこう画期的だった(便利)

S2Dao だけを個別に強調するつもりはないけど、こんな感じかな。
>>95 の言うとおり、Seasar2 （正式には S2Container)だけでは、DI コンテナ機能しかないので、
web 層の S2Struts とか SASTruts とか Teeda を、
O/Rマッパは S2Dao とか S2JDBC とかを組み合わせて使う。

0098デフォルトの名無しさん

2009/05/23(土) 03:15:21

>>97
去年まで海外いたが聞いたことなかったぞ
seasar2ってそんなに話題集めてた？

0099デフォルトの名無しさん

2009/05/23(土) 03:23:04

海外ではほとんど使われてないと思うよ

0100デフォルトの名無しさん

2009/05/23(土) 03:35:18

国産で話題って話なのに
なんで反論が海外じゃ知られてないになるのか解らん

0101デフォルトの名無しさん

2009/05/23(土) 04:47:49

>>100
意味不明

0102デフォルトの名無しさん

2009/05/23(土) 04:58:34

去年まで海外いたが(日本で話題になってるなんて)聞いたことなかったぞ
seasar2って(日本では)そんなに話題集めてた？

という解釈も不可能ではない

0103デフォルトの名無しさん

2009/05/23(土) 05:19:39

不可能ではないが、そんな解釈するのは>>100だけだろｗ

0104デフォルトの名無しさん

2009/05/23(土) 05:22:30

海外で使われてなければいけないと思ってる人は何を懸念してるんだろう。
オフショア開発でもしたいのかな。

0105デフォルトの名無しさん

2009/05/23(土) 05:29:45

ML見てると日本語読めない外人にSeasar使わせるのはかわいそう

0106デフォルトの名無しさん

2009/05/23(土) 05:33:02

現在の位置付け的には、S2は日本向けでSlim3が海外向けなんでしょ
GAEとかはあまり興味ないからよくわからん

0107デフォルトの名無しさん

2009/05/23(土) 13:22:53

>>104
考え方がおかしい…「海外で使われてなければいけない」なんて記載ないだろｗ
本当に良い物だったら利用者は海外や国内問わず使いたいだろうし、提供者からすれば使って欲しいでしょ

0108デフォルトの名無しさん

2009/05/23(土) 13:37:30

既存の洋物プロダクトじゃ不満な部分を日本の事情に合わせて作ったのがS2だろ
公式サイトも殆ど日本語だし別に世界的にやっていこうとは思ってないだろ

0109デフォルトの名無しさん

2009/05/23(土) 14:37:43

カンファレンスのセッション内容まだ決まってないの？
いつもこんなんだっけ？

0110デフォルトの名無しさん

2009/05/23(土) 14:40:59

10日前に何も決まってないのは初めてかもしれんな
決まってた物が直前に入れ替えみたいなのはあったけど

0111デフォルトの名無しさん

2009/05/23(土) 15:15:15

今日は6月3日だったのか

0112デフォルトの名無しさん

2009/05/23(土) 15:17:34

普通は出し物が決まってから参加申し込みうけつけるんじゃ

0113デフォルトの名無しさん

2009/05/23(土) 15:18:15

>>108
s2のHP見たがそんな記載はどこにもないんだが…

0114デフォルトの名無しさん

2009/05/23(土) 15:35:04

このプロダクトが生まれた歴史みたいなのを公式に記述してる所なんて普通無いのでは
ｽﾘﾑｻﾝのblogでも追うがよろし

0115デフォルトの名無しさん

2009/05/23(土) 15:59:38

>>114
公式HP載ってないからblog見ろって意味不明

0116デフォルトの名無しさん

2009/05/23(土) 16:06:44

開発者がインタビューでこぼれ話として語ることはあっても、
公式サイトでいちいち、こういう理由があったからこの製品は作られたのです
みたいな表明している製品はあんまないだろって話じゃないの？
だから作者のblogでも見れば書いてるんじゃないの？って事でさ。

0117デフォルトの名無しさん

2009/05/23(土) 16:12:45

日本の事情に合わせては知らんが開発を始めた経緯はmlのこのスレ見れ
http://ml.seasar.org/archives/seasar-user/2004-January/000325.html
既存の洋物じゃ不満な部分はこれかな
http://ml.seasar.org/archives/seasar-user/2004-January/000328.html

0118デフォルトの名無しさん

2009/05/23(土) 16:32:57

>>117
ソースあり(´▽｀*)

だが日本固有の事情ではないね
>>108はどこから日本の事情って勘違いしちゃってるんだ？

0119デフォルトの名無しさん

2009/05/23(土) 16:43:20

Strutsに絡めないと企業で使われないからって
S2StrutsやSAStrutsをメインに据えたのは日本の事情だぜ

0120デフォルトの名無しさん

2009/05/23(土) 16:50:06

設定ファイルを書かせると間違えるから自動バインディングをデフォにしたのも
日本固有の事情かもしれん

0121デフォルトの名無しさん

2009/05/23(土) 16:51:58

とりあえず意見を否定する前に作者のblogを一通り見るくらいしてくれたまえ
MLも公式サイトも作者の私物じゃないんだから独り言は垂れ流されてないんだからさ

0122デフォルトの名無しさん

2009/05/23(土) 17:37:00

Slim3はGAE専用？
S2JDBCみたいなO/Rマッパ搭載なし？
GAEなんぞしばらく使う予定無いんだがな…

0123デフォルトの名無しさん

2009/05/23(土) 17:44:54

いやだからｽﾘﾑｻﾝのブログに書いてるだろ

0124デフォルトの名無しさん

2009/05/23(土) 17:51:08

このスレの趣旨を分かってないやつが増えたな
ここはｽﾘﾑｻﾝやデブや代表理事をヲチして突っ込むスレなんだよ
ブログのヲチもしない素人はすっこんでろ

0125デフォルトの名無しさん

2009/05/23(土) 18:24:17

おまえこそすっこめ

0126デフォルトの名無しさん

2009/05/23(土) 18:25:07

blog見るの面倒じゃん。
見るだけの根拠もないしな
それに日本の事情って定義も曖昧だしな

誰か何か言えば否定とかキャパ狭すぎ
大したスキルないこと丸わかりな感じ
絡んでるのがそんな奴しかいないプロダクトに見切りをつけはじめた

人に素人っていう奴が実は一番何もわかってたりするわな

0127デフォルトの名無しさん

2009/05/23(土) 18:26:29

>>126
>人に素人っていう奴が実は一番何もわかってたりするわな

人に素人っていう奴が実は一番何もわかってなかったりするわな

だろｗ

0128デフォルトの名無しさん

2009/05/23(土) 18:29:37

>>127
突っ込み速っ!!!

0129デフォルトの名無しさん

2009/05/23(土) 19:31:55

>>127
実は褒めているんだよｗ

0130デフォルトの名無しさん

2009/05/23(土) 20:16:10

(1)公式見る
(2)MLを見る
(3)コミッタのblogなどを見る
(4)MLやblogで質問する
ってのが普通なのであって
匿名掲示板で一方的に不満たらたらくだ巻いてるのはだいたい情弱なんだよ

0131デフォルトの名無しさん

2009/05/23(土) 20:32:31

あとあれだな
個人的な中傷だったり、詳しい人に反論されてフルボッコになるのが嫌で
公に意見できなかったりする感じのがここに集まってるな

0132デフォルトの名無しさん

2009/05/23(土) 20:51:52

あとあれだな
個人的な中傷だったり、詳しい人に反論されてフルボッコにされた誰かを
ヲチして楽しんでる感じのがマ板に集まってるな

0133デフォルトの名無しさん

2009/05/23(土) 20:55:01

時間があったのでSAStrutsをさ、とりあえずサンプルを動かして見ている段階なんだけど、
雛型の作成であれば、Doltengによって雛型を作成できることから、それほどクラス設計は悩まなくてもいい事が解った。
S2JDBCとS2Daoについては、S2JDBCはどうやらDaoを必要としないケースでのデータベースアクセスに使用するものだね。
僕は、Daoをさ、画面単位に持ちたいから、どちらかといえばS2Daoを使用したいね。O/Rマッピングツールと同様に、
DaoやDTOを自動生成できるツールもあるみたいで、なかなか便利だなって思っていました。
Daoの仕様について、僕はprepareStatementを使用したものが主流だと思っているんだけど、prepareStatementでも、
SQL文をプロパティファイルに記述し外出しすることにより、依存性の注入は可能だよね？
S2Daoの使用も見てみましたが、こちらはSQLファイル単位で外出し、引数に関してはARGSアノテーションを使用する。
S2Daoにおいて依存性の注入の方式が、クラス名+メソッド名と同じファイルのSQLが呼び出される？で実現するようで、
正直に言って、ちょっとびっくりしました。dao.diconにはDaoクラス名は設定するけど、
メソッドとSQLファイルに関連する定義されていない。これがAOPと呼ばれる処理に該当するんだろうね。
AOPに関してはもう少し検証しなければ、正確には把握できない。また、DTOに関しては、
テーブル定義そのままをDTOに保持する事になることから、処理速度が心配になりつつも、
いずれにしても、わりとコアな内容の仕様なんで、僕なんかこういうの見てぞくぞくするので、好きだけどね。

0134デフォルトの名無しさん

2009/05/23(土) 23:27:09

ひがやすを blogみたが
社会やら個人に対する否定＆文句ばっかじゃんｗ

0135デフォルトの名無しさん

2009/05/24(日) 01:40:34

>>133
△クラス名+メソッド名と同じファイルのSQLが呼び出される？で実現するようで、
○Daoメソッド実行時に、クラス名+メソッド名と同じ名称を持つSQLファイルが呼び出される。

0136デフォルトの名無しさん

2009/05/24(日) 03:51:57

現状に満足してる奴は新しい物を生み出せないからな
不満があるから自分で何か違う物を作ろうとする

0137デフォルトの名無しさん

2009/05/24(日) 04:26:38

ｷﾘｯ

0138デフォルトの名無しさん

2009/05/24(日) 07:06:40

だっておｗｗｗっｗ

0139デフォルトの名無しさん

2009/05/24(日) 07:14:36

クスクス

0140デフォルトの名無しさん

2009/05/24(日) 08:15:40

で、結局、slim3の通常のrdbms操作は何使えばいいのさ

0141デフォルトの名無しさん

2009/05/24(日) 14:49:15

>>134
>>136

どうなんだろうね。JavaEEに関して悲観的になっているのが、少し気になるね。
GAEに意識が集中しているようで、もちろん僕よりも業界や幅広い技術的な情報を収集している人だろうけど、
完全にさ、Struts系のフレームワークを捨てるとなるとさ、僕なんか少しがっかりしちゃうよね。
新しい事に挑戦するとこは悪いことではないので否定はしないけど、Struts系のフレームワークを
完全に捨てる方針は、もう少し慎重に判断してもらいたいと思いますね。

0142デフォルトの名無しさん

2009/05/24(日) 16:13:39

>>140
GAE/JでRDBは使えないから心配するな

>>141
GAE/J専用フレームワークSlim3でStrutsを捨てただけ
SAStrutsが捨てられたわけじゃない

0143デフォルトの名無しさん

2009/05/24(日) 16:25:51

日本語読解力が弱い人が多いと思う
だからMLで聞けないで掲示板で一方的に懸念を表明する

0144デフォルトの名無しさん

2009/05/24(日) 17:03:33

>>142
そうですか。GAEに関しては調べましたが、僕の視点からはPHPと同レベルに見え、
スクリプトレベルの開発環境と判断。したがって、僕の視点からはGAEは軽視しますね。
僕としては企業用のコアなJavaEEの方が、好きだけどね。
仮にSeasarがGoogleとの互換性を重視するあまりに、軽量なJavaを選択するのであれば、
僕としてはSpringに移行する事も想定に入れなければならない。

0145デフォルトの名無しさん

2009/05/24(日) 17:04:49

ｽﾘﾑｻﾝがテストで対応してる環境に対して
それは方向性が違う俺たちは捨てられたとか騒ぐなよ
アホかお前ら

0146デフォルトの名無しさん

2009/05/24(日) 17:06:36

>>144
僕はバカまで読んだ

0147デフォルトの名無しさん

2009/05/24(日) 17:10:39

好きなら文句言わずにJavaEE使ってればいいと思うんだけど

0148デフォルトの名無しさん

2009/05/24(日) 17:16:28

GAEがPHPと同レベルって笑うところ？笑えないけど

0149デフォルトの名無しさん

2009/05/24(日) 17:21:39

slim3はseasarじゃないって知らない人がいるね

0150デフォルトの名無しさん

2009/05/24(日) 17:23:35

アホだから直接ｽﾘﾑｻﾝのblogで質問したりMLに投げたりできないんだろ
違いますよ何言ってるんですかって1秒で言われて終わりになるのが
自分でも解ってるから

0151デフォルトの名無しさん

2009/05/24(日) 17:25:28

>>147
ひがやすを氏が、SeasarとSlim3のプロジェクトを兼務しているので、論理が倒錯する局面が発生するので、
ユーザーとしては、そういう時に若干戸惑うかもしれないね。

0152デフォルトの名無しさん

2009/05/24(日) 17:31:28

>>144
Seasar2もSpringもJ2EEに対するアンチテーゼとして生まれ、
当時は軽量コンテナと呼ばれていた
これ豆知識な

0153デフォルトの名無しさん

2009/05/24(日) 18:12:07

どなたかSeaser.NETをお使いの方いらっしゃいませんか？
利用実績がある程度あればプロジェクト採用になるのですが・・・

0154デフォルトの名無しさん

2009/05/24(日) 20:47:40

>>153

どうなんだろうね。僕はJavaしかやったことがないで、解らないけど誰か.NET詳しい人います？
.netでもさ、S2Daoと同じ仕様なんで、例えばデータベースアクセスの際にVersionNoやTimestampによる
排他制御が実装されている。僕は.netでもSeasarを使う利便性は高いと思うけどね。

0155デフォルトの名無しさん

2009/05/24(日) 20:55:05

.NETならS2よりEnterprise Libraryのほうが提案しやすいけどな

0156デフォルトの名無しさん

2009/05/24(日) 20:55:34

>>153

うちではQuillつかってるよ。

DotNetって標準のWindowsFormsじゃあちょいとばかり非力だし
生のAdo.Netは使いにくいし、LinQforAdo.Netはカオスだし
S2Dao＋Quillコンテナは、なんだかんだで便利。

まあ個人的にはDBアクセスはIBatis.Netのほうがいいじゃんって気もするけど。

0157デフォルトの名無しさん

2009/05/24(日) 21:13:19

>>141
嫌いなら別に使わなくていいと思う。
Servlet/JSPやJTAもJavaEEだから使うのやめればいいのに。
1からサーブレットAPIもどきから作るといいと思う。

0158デフォルトの名無しさん

2009/05/24(日) 21:15:03

みんなでGAE/Jすりゃ怖くないってか

0159デフォルトの名無しさん

2009/05/24(日) 21:36:24

GAE はまだまだ趣味レベルとしか見られないな

0160デフォルトの名無しさん

2009/05/24(日) 21:54:04

GAEのJava自体がまだテスト段階なんだから当たり前だと思うが

0161デフォルトの名無しさん

2009/05/24(日) 22:19:12

>>154 155 156
サンクス、助かります(;´Д`)
Enterprise Libraryはあまり馴染みがないのですが、
MS謹製ならちょっと考えようと思います

0162デフォルトの名無しさん

2009/05/24(日) 22:47:19

>>153
そういやSpringにも.NET版があるけど、どれ位使われているのかな？

0163デフォルトの名無しさん

2009/05/24(日) 23:56:22

>>162
それは、spring板の人に聞いてよ。でもさ、僕の視点では国産DIを利用した方がいいよ。付随するSAStrutsも高機能だからね。
前々、から言おうと思っていたけどさ、DAOクラスでさ、排他制御も書けない人がspringなんて使っても意味ないよ。

0164デフォルトの名無しさん

2009/05/25(月) 00:08:23

.NET版にもSAStrutsがあるのか。初耳だ。

0165デフォルトの名無しさん

2009/05/25(月) 01:06:10

ないよ
ってか事例だったらMLで聞いたら嫌でも殺到するのになんでまたこんな所で

0166デフォルトの名無しさん

2009/05/25(月) 01:08:33

PHP版はMapleとかあるけど、.NET版はかなり放置プレーだな

0167デフォルトの名無しさん

2009/05/25(月) 01:11:26

僕はJavaそしてSeasarを推薦するよ。S2Daoについて、僕が解りやすく説明するよ？
VersionNoでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
VersionNoが自分の取得したVersionNoと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Timestampでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
Timestampが自分の取得したTimestampと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。

Webシステムにおいては、多数の人が同時に同じDBにアクセスする事になるので、排他制御が抜けているシステムは致命的になる。

0168デフォルトの名無しさん

2009/05/25(月) 02:20:42

しかしながら、S2Daoの排他制御は不完全である。
理想としては、画面表示のselect時にVersionNoとTimestampを取得する仕様が好ましい。
今のS2Dao仕様では、Daoレベルでのデータベース更新の瞬間的な排他制御はできる。
そうではなくて、画面表示のselect時にVersionNoとTimestampを取得し、
｢画面単位｣で排他制御を行うのが正しい。S2Daoの排他制御もまた素人臭い。

0169デフォルトの名無しさん

2009/05/25(月) 02:36:38

カンファレンスにｷｼﾀﾞﾀﾝでないかなぁ

0170デフォルトの名無しさん

2009/05/25(月) 02:40:23

>>168の訂正

失礼、ActionクラスからselectしDTOからActionFormに詰め替え際に、VersionNoあるいはTimestampもActionFormにsetする。
データベース更新時は、ActionFormからDTOに詰め替えする際に、select時に取得したVersionNoあるいはTimestampを
DTOに設定する事で、画面単位での排他制御が実現できる。

0171デフォルトの名無しさん

2009/05/25(月) 03:07:04

これができていないWebシステムはゴミだ。

0172デフォルトの名無しさん

2009/05/25(月) 03:29:32

若干混乱したので要約すると、

>>167○この概念はSeasarの公式にも書かれているので正しい
僕はJavaそしてSeasarを推薦するよ。S2Daoについて、僕が解りやすく説明するよ？
VersionNoでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
VersionNoが自分の取得したVersionNoと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Timestampでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
Timestampが自分の取得したTimestampと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Webシステムにおいては、多数の人が同時に同じDBにアクセスする事になるので、排他制御が抜けているシステムは致命的になる。

>>168×これは僕の認識の誤りである可能性が高い
しかしながら、S2Daoの排他制御は不完全である。
理想としては、画面表示のselect時にVersionNoとTimestampを取得する仕様が好ましい。
今のS2Dao仕様では、Daoレベルでのデータベース更新の瞬間的な排他制御はできる。
そうではなくて、画面表示のselect時にVersionNoとTimestampを取得し、
｢画面単位｣で排他制御を行うのが正しい。S2Daoの排他制御もまた素人臭い。

>>170○S2Daoの振る舞いが以下の使用に適合していれば、理想的な排他制御になる。検証してみなければ解らないが、暫定でできると仮定。
失礼、ActionクラスからselectしDTOからActionFormに詰め替え際に、VersionNoあるいはTimestampもActionFormにsetする。
データベース更新時は、ActionFormからDTOに詰め替えする際に、select時に取得したVersionNoあるいはTimestampを
DTOに設定する事で、画面単位での排他制御が実現できる。

>>171○ゴミです
これができていないWebシステムはゴミだ。

0173デフォルトの名無しさん

2009/05/25(月) 11:43:47

あ、いっぱい進んでる。

Rails使ったことないんだけど、
Railsはどのあたりが本質的で面白いか聞きたいのだけど、、、。

0174デフォルトの名無しさん

2009/05/25(月) 19:12:26

やべえ…
排他バカにみんな呆れて、過疎ってきた

0175デフォルトの名無しさん

2009/05/26(火) 00:31:44

>>168は楽観的ロック知らないのかなと思った
あと更新に失敗したら再度トランザクションやりなおしさせる処理が抜けてるシステムも多い

楽観的ロックは開発者に負担を強いるからね

0176デフォルトの名無しさん

2009/05/26(火) 00:41:32

>>168の言ってるのが楽観的ロックに見えるけど？

0177デフォルトの名無しさん

2009/05/26(火) 01:26:32

通常の楽観的ロックはトランザクション開始前に取得したものを使う

0178デフォルトの名無しさん

2009/05/26(火) 03:25:49

>>175
更新用データ取得時にバージョンカラムの値も取得しておいて
画面上ではhidden値にでも入れておいて
更新するときのBeanにその値を詰めておくだけだろ
アップデート文はFWが自動発行してくれるんだし
この程度を負担とか言っていたら、何も任せられないよ

0179デフォルトの名無しさん

2009/05/26(火) 08:16:32

>>178
負担ってのはどう考えても更新失敗時の例外処理の面倒さだろ。

0180デフォルトの名無しさん

2009/05/26(火) 13:34:25

節子、それ楽観ロックやない、悲観ロックや

0181デフォルトの名無しさん

2009/05/26(火) 13:54:48

>>178 が言っていることも楽観的ロックだと思うけど？

悲観的ロックというのは、その画面を誰かが開いている間、
ロックテーブルとかにレコードを入れて、他のユーザは強制的に入れないようにするような手法だと思っています。

0182デフォルトの名無しさん

2009/05/26(火) 18:26:02

そうだね。S2Daoによる楽観的ロックを行い、
後はさ、ユーザーに最終更新日によって確認してもらうのがいいよね。
楽観的ロックでもさ、多数のユーザーが同時に同じ操作を行った際には、
エラーメッセージによって、PrimaryKeyや名称を表示して、
「他のユーザーが同じ操作を行っています。
しばらく待つかまたはシステム管理者にお問い合わせください。」等の
メッセージとしてユーザーに対するお知らせが可能になるよね。
但し、この排他制御はユーザーが同時に同じ操作を行ったケースなんで、
5分前や1時間前に更新されたケースに関しては、
最終更新日の表示によってユーザーに気をつけてもらうしかなかなか方法がないよね。
もちろん、間に承認システムやバッチ処理があれば、
承認者が重複等の異常に気づくことも可能ではあるし、
そういった方式を取ることもあると思いますが、
後はさ、お金が絡む対象も存在するのでログテーブルも必要でしょう。

こういう事も考えていくとさ、僕なんかはやっぱりJavaEEを採用する方がいいと思うけどね。
単純でリスクの少ないWebアプリであれば、何を使用してもいいと思うけど、
実際に企業用のWebシステムとなると、こういう事もきちんと実装しないと正常稼働しないからね。
もちろん、僕はさ、ほらIT志望の大学生なんで、まだ皆さんよりは詳しくはないんですが、
話がSEよりになってしまっているので、プログラミング技術よりの話を展開していくのがいいと思いますし、
実際に、Webシステム作って排他制御とAOPを検証してみるよ。

0183デフォルトの名無しさん

2009/05/26(火) 19:12:59

５分前だろうが１時間前だろうが、更新用に取得したデータを
他に誰も更新していない状態で自分が更新したときにだけ成功するのだから関係ない

あと、JavaEEで楽観的排他をサポートしているのはJPAだが、
基本的にやってることは同じだから特に違いはない

0184デフォルトの名無しさん

2009/05/26(火) 21:22:47

>>178がいってるのはアプリケーションコントロールのロックな
更新時には悲観的ロックかもしれない

0185デフォルトの名無しさん

2009/05/26(火) 21:25:23

>>181
おいおい
このスレでわかりやすい嘘つくんじゃない

0186デフォルトの名無しさん

2009/05/26(火) 21:49:34

>>183

そうだね。DBの仕様が通信販売や予約システム等の早い者勝ちの仕様であれば、
あるいは銀行等の常に上書きされべき対象であれば、楽観的ロックだけで済む問題だけど、
民間企業用のさ、顧客に対する情報の更新等は、複数の担当者が重複して入力する可能性もあるので、
それは楽観的ロックだけでは、回避できないって話だよ。

0187デフォルトの名無しさん

2009/05/26(火) 21:52:55

>>183の追記

失礼、銀行のDBであれば参照用からマスターへの更新の際には、整合性チェックも含め
間に、承認やバッチ処理が必要だけどね。わかりやすく表現しただけなんで、そこの差異は理解して貰えると思います。

0188デフォルトの名無しさん

2009/05/26(火) 21:55:50

ジミ・ヘンドリックス
グリーン・デイ
ニルヴァーナ
チャック・ベリー
エルヴィス・プレスリー
ローリング・ストーンズ

0189デフォルトの名無しさん

2009/05/26(火) 22:02:18

ロックしないのに楽観的ロックって言葉が変だよね
ビールじゃないのに第三のビールみたいでさ

0190デフォルトの名無しさん

2009/05/26(火) 22:04:42

>>186

こういったケースでは、楽観的ロックだけでは回避できないので、画面に表示されている最終更新日によって、
ユーザーに変更していいのかを判断してもらいたい。また、間に承認システムやバッチ処理があれば、
重複した際に、承認者によって、どちらが正なのかを判断してらわなければならないということですよ。
その問題は、同時にシステム管理者への問い合わせとして、誰がいつどのDBを変更したかを把握しなければならないので、
ログテーブルも必要でしょう。と、僕がおっしゃってるわけですよ。

0191デフォルトの名無しさん

2009/05/26(火) 22:15:52

>>188そっちのロックじゃねぇ

0192181

2009/05/26(火) 22:19:35

>>185
え、ちがうの？？

○楽観的ロック：

・画面表示(HTML 表示時)に、そのレコードの version_id なり最終更新日時を hidden で持たしておく
・HTML にデータを入力して submit 後、サーバサイドに渡ってきた version_id や最終更新日時を where 句にして

　select * from HOGE where 受注番号 = **** and versin_id = {画面から渡ってきたもの} for update

　して、レコードが取得できればそのまま update 文で更新
　レコードが取得できなければ、version_id がインクリメントされていることが考えられるので、
　画面に「他のユーザがすでに更新しました。データを再検索してください」

　こんな感じ

○悲観的ロック：

　ある画面を開いた時点で、その画面に排他制御をかけ、誰も入れなくする
　（業務仕様上、その画面が編集するテーブルは、その画面でしか更新できないことが条件)

だとおもっていたよ。

誰か添削してくれ

0193デフォルトの名無しさん

2009/05/26(火) 22:34:31

>>192
いちいちせぇctしないでうpだてすりゃいいだろjk

0194デフォルトの名無しさん

2009/05/26(火) 22:41:29

>>190の追記

楽観的ロックでも悲観的ロックでも、同じ振る舞いになる。

0195デフォルトの名無しさん

2009/05/26(火) 23:02:58

>>192
悲観的ロックがすごいな
俺ならそんなシステム使いたいと思わない

>>194
俺も回避できないからどうリカバリーするかを考える方が好きだ

0196デフォルトの名無しさん

2009/05/26(火) 23:04:30

>>192
それはアプリケーション制御の話。つまりただの仕様であり運用方法。

通常楽観的ロックや悲観的ロックというのはDBアクセスで読み込み中心ならば
ロックをかけないようにしよう、後から来たほうはトランザクションをリトライさせればいいんじゃね?
というお話だからミリ秒単位のお話。

だからリトライ制御等がはいってないのは楽観的ロックですらなく、書き込みもそれなりにあるのならば
普通に悲観的ロックをかけたほうが良い。

よくあるATMでの振込みと引落の同時アクセスを考えてみると良い。

ただ、読み込みでロックかけるようなDBなら楽観的ロックのほうが有利にはなりやすい可能性あり。

楽観的ロックというのはデータベースのロックを積極的に利用しようという話ではないので
開発者側に負担を強いる方法。楽観的であれ短い時間だろうが更新時にはどうせロックかけるので
実はアクセス順序を意識しないとデッドロックの可能性が普段から意識する悲観的ロックより
大幅に増える。IF文等によりアクセスするテーブルや行が変わる可能性があるからね。

■ このスレッドは過去ログ倉庫に格納されています