国産DIコンテナSeasar その15
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/03/17(火) 20:48:19ってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをblog
http://d.hatena.ne.jp/higayasuo/
前スレ
その1 http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その2 http://pc5.2ch.net/test/read.cgi/tech/1098885253/
その3 http://pc8.2ch.net/test/read.cgi/tech/1102862221/
その4 http://pc8.2ch.net/test/read.cgi/tech/1119608621/
その5 http://pc8.2ch.net/test/read.cgi/tech/1135986150/
その6 http://pc8.2ch.net/test/read.cgi/tech/1148204750/
その7 http://pc8.2ch.net/test/read.cgi/tech/1153060167/
その8 http://pc10.2ch.net/test/read.cgi/tech/1165531719/
その9 http://pc11.2ch.net/test/read.cgi/tech/1170674234/
その10 http://pc11.2ch.net/test/read.cgi/tech/1176050197/
その11 http://pc11.2ch.net/test/read.cgi/tech/1190846507/
その12 http://pc11.2ch.net/test/read.cgi/tech/1203122931/
その13 http://pc11.2ch.net/test/read.cgi/tech/1215962870/
その14 http://pc11.2ch.net/test/read.cgi/tech/1224157275/
0185デフォルトの名無しさん
2009/05/26(火) 21:25:23おいおい
このスレでわかりやすい嘘つくんじゃない
0186デフォルトの名無しさん
2009/05/26(火) 21:49:34そうだね。DBの仕様が通信販売や予約システム等の早い者勝ちの仕様であれば、
あるいは銀行等の常に上書きされべき対象であれば、楽観的ロックだけで済む問題だけど、
民間企業用のさ、顧客に対する情報の更新等は、複数の担当者が重複して入力する可能性もあるので、
それは楽観的ロックだけでは、回避できないって話だよ。
0187デフォルトの名無しさん
2009/05/26(火) 21:52:55失礼、銀行のDBであれば参照用からマスターへの更新の際には、整合性チェックも含め
間に、承認やバッチ処理が必要だけどね。わかりやすく表現しただけなんで、そこの差異は理解して貰えると思います。
0188デフォルトの名無しさん
2009/05/26(火) 21:55:50グリーン・デイ
ニルヴァーナ
チャック・ベリー
エルヴィス・プレスリー
ローリング・ストーンズ
0189デフォルトの名無しさん
2009/05/26(火) 22:02:18ビールじゃないのに第三のビールみたいでさ
0190デフォルトの名無しさん
2009/05/26(火) 22:04:42こういったケースでは、楽観的ロックだけでは回避できないので、画面に表示されている最終更新日によって、
ユーザーに変更していいのかを判断してもらいたい。また、間に承認システムやバッチ処理があれば、
重複した際に、承認者によって、どちらが正なのかを判断してらわなければならないということですよ。
その問題は、同時にシステム管理者への問い合わせとして、誰がいつどのDBを変更したかを把握しなければならないので、
ログテーブルも必要でしょう。と、僕がおっしゃってるわけですよ。
0191デフォルトの名無しさん
2009/05/26(火) 22:15:520192181
2009/05/26(火) 22:19:35え、ちがうの？？
○楽観的ロック：
・画面表示(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いちいちせぇctしないでうpだてすりゃいいだろjk
0194デフォルトの名無しさん
2009/05/26(火) 22:41:29楽観的ロックでも悲観的ロックでも、同じ振る舞いになる。
0195デフォルトの名無しさん
2009/05/26(火) 23:02:58悲観的ロックがすごいな
俺ならそんなシステム使いたいと思わない
>>194
俺も回避できないからどうリカバリーするかを考える方が好きだ
0196デフォルトの名無しさん
2009/05/26(火) 23:04:30それはアプリケーション制御の話。つまりただの仕様であり運用方法。
通常楽観的ロックや悲観的ロックというのはDBアクセスで読み込み中心ならば
ロックをかけないようにしよう、後から来たほうはトランザクションをリトライさせればいいんじゃね?
というお話だからミリ秒単位のお話。
だからリトライ制御等がはいってないのは楽観的ロックですらなく、書き込みもそれなりにあるのならば
普通に悲観的ロックをかけたほうが良い。
よくあるATMでの振込みと引落の同時アクセスを考えてみると良い。
ただ、読み込みでロックかけるようなDBなら楽観的ロックのほうが有利にはなりやすい可能性あり。
楽観的ロックというのはデータベースのロックを積極的に利用しようという話ではないので
開発者側に負担を強いる方法。楽観的であれ短い時間だろうが更新時にはどうせロックかけるので
実はアクセス順序を意識しないとデッドロックの可能性が普段から意識する悲観的ロックより
大幅に増える。IF文等によりアクセスするテーブルや行が変わる可能性があるからね。
0197181
2009/05/26(火) 23:05:15おっしゃるとおりなので、悲観的ロックをかける場所は、
たとえば「年次締めバッチ起動画面」など、重要で、誰か一人しか使えなくすべき画面にのみに適用し、
普通のところは、 >>192 の楽観的ロックを使う、と思っているのですが。
0198デフォルトの名無しさん
2009/05/26(火) 23:12:33（´；ω；） ｶﾜｲｿｽ
0199デフォルトの名無しさん
2009/05/26(火) 23:13:01POEAA読めば終わりだろ？読んでないの？素人？
0200デフォルトの名無しさん
2009/05/26(火) 23:36:49たまには動物園に行きたくなるだろ？
0201デフォルトの名無しさん
2009/05/26(火) 23:42:34俺もupdateのwhere句に条件加えればいいじゃんと思うんだが
0202デフォルトの名無しさん
2009/05/26(火) 23:57:59まあそういうな
s2コミッタ＝素人
s2ユーザ＝ど素人
なんだからさｗ
0203181
2009/05/26(火) 23:58:45select .... for update してレコードが取得できたかどうかをせずに、
いきなり update 文を実行した場合、
update 文の結果(PreapredStetement#exeucte())で、0 が返って来た場合、
version_id がずれて更新できなかったのか、
そもそも、当該受注番号のレコードが、一瞬先に別ユーザによって消されたのかわからない。
select .... for update してレコードが取得できたかチェックしておいて、レコードが得られなかったら、
「他のユーザがすでに更新しました or 他のユーザがそのデータを消しました」
とエラーメッセージを出すことが出来る。
とここまで書いたが、いきなり update 文を実行して、update 文の結果が 0 だったら、
同じようなメッセージを出せばいいのか。
画面で、ユーザにもう一度画面を開いてもらい、当該受注番号のレコードが消されたら、
画面を開き直したときに、そのレコードは現れなくなるし。
0204デフォルトの名無しさん
2009/05/27(水) 00:20:410205デフォルトの名無しさん
2009/05/27(水) 00:33:30どうしてJavaEEのほうがいいという結論に達したのか、全然わからなかった。
0206デフォルトの名無しさん
2009/05/27(水) 00:35:25実装が違うだけで目的は同じなんだから
JavaEEでもできるだろうけど他でもできるわけで
だからといってJavaEEが最高ってことにはならん
0207デフォルトの名無しさん
2009/05/27(水) 00:38:230208デフォルトの名無しさん
2009/05/27(水) 03:10:52実際のところ、楽観的排他制御対応を謳っているFWはほとんど
UPDATE文にバージョンカラム値を条件に加えて、結果が０だったらエラーにする実装をしている
更新なのか削除なのかは、エラー後に再検索して判断する
そもそも「楽観的排他」は「あまり起こらない」ことを前提として、起こった場合は最初からやり直し
という方針で採用されることが多いから、SELECT FOR UPDATEを使う実装は少ないと思う
（オプションによって、一度空更新してトランザクション的なロックをかけたり・・・とかはあるけど）
0209デフォルトの名無しさん
2009/05/27(水) 05:59:32楽観的ロックでは、1つのトランザクションで複数のテーブルまたは複数のレコードを更新する際には、
デッドロックやそれに伴うデータの不整合になる危険性がある。したがって、1つのトランザクションで
1つのテーブルと1つのレコードを更新する事によりデッドロックの回避が可能になりますが、
これに基づいてDB設計と画面設計は相当慎重に行うべきである。また、S2Daoの排他制御は楽観的ロックなんで、
標準的なDaoクラスでDriverManager.getConnection().setAutoCommit(false)の設定をして
SelectForUpdateによる悲観的ロックを採用した方がシンプルでいいかもしれないね。
加えて、1つのトランザクションで複数のテーブルまたは複数のレコードを更新するケースでは、
rollbackを行えば、データの不整合は改善されるが、Webシステムで更新順序によるデッドロックの回避が
できるのかについては、現時点では僕の把握ではできないと思ってる。
0210デフォルトの名無しさん
2009/05/27(水) 06:15:43要約すると、
・1つのテーブルと1つのレコードを更新する仕様にする(デッドロックが起きないケース)
・デッドロックが起きた際には、rollbackよって回復する(デッドロックをrollbackによって回復するケース)
0211デフォルトの名無しさん
2009/05/27(水) 07:42:20やはりこの程度の認識だったのか・・・
0212デフォルトの名無しさん
2009/05/27(水) 08:33:380213デフォルトの名無しさん
2009/05/27(水) 08:41:39複数テーブルを更新するときはFOR UPDATEを付けるし、
設計次第ではデッドロックも起きる。
そこは悲観的・楽観的とは関係ないんだよ。僕ちゃん。
0214デフォルトの名無しさん
2009/05/27(水) 08:47:22さらに要約すると、排他制御はSelectForUpdateによる悲観的ロックを行い、デッドロック対策としては
1画面に可能な操作は、1つのトランザクションで1つのテーブルと1つのレコードを更新するだけに限る。
また、最終更新日を表示することにより、ユーザーによって変更してもよいデータであるかを判断してもらう必要がある。
0215デフォルトの名無しさん
2009/05/27(水) 09:31:39これを実現する画面設計としては、検索リストから詳細画面へ遷移し、登録/更新/削除を行う。
DB設計も、1画面に可能な操作は、1つのトランザクションで1つのテーブルと1つのレコードを更新する事を踏まえ
データモデリングしていく必要があるね。
0216181
2009/05/27(水) 11:03:15181=192=197=203 です。
182=209 、その他ではありません
(まぁ似たようなレベルかも知れませんが)
0217デフォルトの名無しさん
2009/05/27(水) 11:10:480218デフォルトの名無しさん
2009/05/29(金) 14:09:320219デフォルトの名無しさん
2009/05/30(土) 00:51:17しかも事例紹介を大部屋でやって、ひがさんのセッションを30人の部屋でやるとは…
0220デフォルトの名無しさん
2009/05/30(土) 00:57:08しかし実務やってる人には新技術より事例発表の方があるから人は集まるだろうけど
実例がSAStrutsとかみたいな今企業でよく使われるような物じゃないから
微妙なんだよなぁ
0221デフォルトの名無しさん
2009/05/31(日) 01:06:4815分か。。
0222デフォルトの名無しさん
2009/05/31(日) 01:10:040223デフォルトの名無しさん
2009/05/31(日) 02:59:51今からメールしたら、変えてくれるかも。
Seasar カンファレンスは、いつも聞きたいのが重なりすぎて困る。
0224デフォルトの名無しさん
2009/06/01(月) 22:55:40SearchSearvice searchSearvice;
てな感じで、SearchSearviceのオブジェクトのコンストラクタとかプロパティにデフォルトで値をセットできればええのになぁ。
0225デフォルトの名無しさん
2009/06/02(火) 00:13:35アノテでやったら型が違ってたら何処でエラー出てるのか解らん
0226デフォルトの名無しさん
2009/06/04(木) 13:30:45@Resource(arg="@Arg(arg1="aaa",arg2="bbb",arg3="ccc"))
SearchService searchService;
てな感じで、SearchSearviceのオブジェクトのコンストラクタとかプロパティにデフォルトで値をセットできればええのになぁ。
と思うぞ。
英語勉強しろよ。
0227デフォルトの名無しさん
2009/06/04(木) 17:39:14タイプセーフにならんだろ
0228デフォルトの名無しさん
2009/06/04(木) 23:59:48form.TestForm.java に、
public Map<String,String> testMap;
を宣言して、
action.TestAction.java で
@ActionForm
@Resource
public TestForm testForm;
とした。
jspに、
<html:text property="testMap(test)" ></html:text>
として、入力した値が、testMap.get("test")で取れるようにしたい。。しかし、、
java.lang.UnsupportedOperationException: get
org.seasar.struts.action.ActionFormWrapper.get(ActionFormWrapper.java:113)
と出てしまう。どこか間違ってるか別の方法があるか、、、教えてえろいひと
0229デフォルトの名無しさん
2009/06/05(金) 00:18:01testMap(test)ってそもそもなんなんだよ
0230デフォルトの名無しさん
2009/06/05(金) 00:24:26やりたいことはsubmitした時のアクションでtestForm.testMap.get("test")で取れるようにしたいんだ。。
testFormに
public String test;
とは置きたくないんだ。Mapに自由に格納したいのだです
0231デフォルトの名無しさん
2009/06/05(金) 00:27:17マニュアルに載ってなくてお前も実装してないならだれもそう実装してないってことでしょ
BeanUtilの該当箇所ラップして自分でカスタマイズしなよ
0232デフォルトの名無しさん
2009/06/05(金) 00:35:33HttpServletRequestから取ってくればええやん
0233デフォルトの名無しさん
2009/06/05(金) 00:45:120234デフォルトの名無しさん
2009/06/05(金) 00:52:430235デフォルトの名無しさん
2009/06/05(金) 00:55:22素で書いたら簡単にできるのにこのフレームワークはこんなこともできないんですか！
みたいな質問が多くて、じゃあフレームワーク使わないで素で書けよって思うことは多々ある。
自由な開発の弊害で苦労して一周回った上で、規約を縛ることの必要性を経験しないと理解できない部分なのかもね。
0236デフォルトの名無しさん
2009/06/05(金) 06:58:31sastrutsはstrutsに縛られてるから仕方ない部分がいくつかある
0237デフォルトの名無しさん
2009/06/05(金) 10:55:370239デフォルトの名無しさん
2009/06/05(金) 14:16:47カンファレンスでもセッションあるみたいだし。
S2Wicketはされてないみたいかな。
0241ひがやすを
2009/06/05(金) 21:39:280242デフォルトの名無しさん
2009/06/05(金) 22:36:150243デフォルトの名無しさん
2009/06/08(月) 01:49:56Slim3は必須のようだ。
0244デフォルトの名無しさん
2009/06/08(月) 23:03:20BigtableとJDOの勝ちパターン
は逆にすべきだろ。
事例発表なんか、聞きたい人少ないと思うんだけど。
0245デフォルトの名無しさん
2009/06/08(月) 23:06:33という意味があると思うから大事だと思うよ。実績をアピールするのも大事
でもメンテされてないプロダクトばかりなのが選択する側としてはつらい
0246デフォルトの名無しさん
2009/06/09(火) 00:09:25SINGLETONにしても、リクエストのたびにInitMethodはしるんで…
0247ひがやすを
2009/06/09(火) 00:32:040248デフォルトの名無しさん
2009/06/09(火) 00:41:21わざわざ2chで質問するってことはよっぽどひねくれてるんだよ
0249デフォルトの名無しさん
2009/06/09(火) 00:44:030250デフォルトの名無しさん
2009/06/09(火) 00:47:08教えられる側は嘘教えられてもだれも訂正してくれないぞ
0251デフォルトの名無しさん
2009/06/09(火) 00:52:10顔文字を使っておちゃらけたほうがいいと思う
0252デフォルトの名無しさん
2009/06/09(火) 00:57:230253デフォルトの名無しさん
2009/06/09(火) 01:01:16質問のMLと雑談の掲示板で使い分けって事で。
0254デフォルトの名無しさん
2009/06/09(火) 01:01:38コンテナ起動前にクラス先にロードしちゃえば？
0255デフォルトの名無しさん
2009/06/09(火) 07:09:540256デフォルトの名無しさん
2009/06/09(火) 09:10:23「map対応してないんだね、糞だね」
っておとしめたいだけなのに、
「素早く対応したよ！2chで質問とかすんなよ」
とか、どう考えても場違い。
0257デフォルトの名無しさん
2009/06/09(火) 20:09:08JavaHouseに比べたら実家くらい快適な場所だわ
0258デフォルトの名無しさん
2009/06/09(火) 20:18:550259デフォルトの名無しさん
2009/06/09(火) 20:41:58ネガキャンしたいだけなんだからこのスレはスルーすればいいのにコミッタが絡んでくるのがウザい。
0260デフォルトの名無しさん
2009/06/09(火) 20:48:140261デフォルトの名無しさん
2009/06/09(火) 21:37:14・完璧な回答ならもちろんだけど、何らかのヒント（もっといえば反応）が欲しい
・回答が無い場合、「なにか知ってるひといません？」と再度聞きやすい。多くのMLはそんな空気じゃない。
・「全文引用すんな、過去レス全部読め」などという人が大きな顔されるのがイヤ
・「どうしてそんなことをするの？」なんていう反応が大嫌い。普通に「できる・できない・こういうことか？」という反応だけでいい。
・質問以外の他人のやりとりをMLだと読まざる得ない状況になりやすいからイヤ
ワガママかね？
0262デフォルトの名無しさん
2009/06/09(火) 21:39:03よっぽどカスみたいなのでもないと今まで一度もないだろ
0263デフォルトの名無しさん
2009/06/09(火) 22:20:10> 多くのMLはそんな空気じゃない。
ML全般の話なのかSeasarのML固有の話なのかはっきりしろ
0264デフォルトの名無しさん
2009/06/09(火) 22:33:26どうしてそんなことをするの？
0265デフォルトの名無しさん
2009/06/10(水) 00:27:560266デフォルトの名無しさん
2009/06/10(水) 00:42:420267デフォルトの名無しさん
2009/06/10(水) 01:19:150268デフォルトの名無しさん
2009/06/10(水) 07:43:002chブラウザで見られないからだ。
0269デフォルトの名無しさん
2009/06/10(水) 12:34:03全然違う話だけど、RSSリーダーもいまいちなれないと思ったら、
2chブラウザで見られないからだ、と>>268見て思った。腑に落ちた
0270デフォルトの名無しさん
2009/06/10(水) 13:20:152chブラウザ風の RSS リーダーがほしい。
0271デフォルトの名無しさん
2009/06/10(水) 14:45:252chブラウザで開発できないからだ、と>>269見て思った。腑に落ちた
0272デフォルトの名無しさん
2009/06/11(木) 09:55:38カスは言うこともカスだな
0273デフォルトの名無しさん
2009/06/11(木) 13:18:520274デフォルトの名無しさん
2009/06/12(金) 00:42:520275デフォルトの名無しさん
2009/06/12(金) 23:01:130276デフォルトの名無しさん
2009/06/13(土) 02:52:340277デフォルトの名無しさん
2009/06/14(日) 04:30:140278デフォルトの名無しさん
2009/06/14(日) 14:48:340279デフォルトの名無しさん
2009/06/14(日) 23:06:17空気読んで、SAStruts in Actionだろ。
0280デフォルトの名無しさん
2009/06/14(日) 23:08:58ちゃんと使ってんのか？
お前みたいなやつはろくに触りもしないで
そのうち、BigTableがいいとか言うんだろ
0281デフォルトの名無しさん
2009/06/14(日) 23:16:32shotﾀｿ乙
0282デフォルトの名無しさん
2009/06/14(日) 23:31:30Ymir
Cubby
T2
SAStruts
Teeda
S2Struts
S2JSF
S2Tapestry
追加訂正してくれ
0283デフォルトの名無しさん
2009/06/14(日) 23:33:53Cubby
T2
SAStruts
S2Struts
Teeda
S2JSF
S2Tapestry
くらいの差はあると思う
0284デフォルトの名無しさん
2009/06/14(日) 23:59:21shotタソのコメント欄見てみろ
Ymir
Cubby
SAStruts
S2Click
S2Struts
T2
Teeda
S2JSF
S2Tapestry
S2Wicket
0285デフォルトの名無しさん
2009/06/15(月) 00:21:134コマ目のひがたんの「BigTable と JDO の勝ちパターン」は、聴講者多数で、LT のあとにもう一度行われた。
Slim3 は、Google App Engine と Bigtable 上でしか使えないの？
あと >>282-284 で、ゆみるが先頭に来ている理由がわからない。
Cubby と SAStruts は使ったことがあり、いちおう(使う側としては)理解しているつもり。
Ymir は http://ymir.seasar.org/docs/1.0.x/user/description を読んだぐらいしか知識がない。
Ymir を否定しているのではなく、Cubby とかSAStruts とくらべてどういう点がよいのか聞いてみたい。
あと、T2 は S2JSF のようなプレゼンテーションのフレームワークではなく、
コントローラやプレゼンテーション層を結びつけるためのフレームワーク
(コントローラやプレゼンテーション層より、レイヤが一段下)ではなかったか？
※法政大学の外堀校舎は綺麗だな。
あんしんしておなか痛くなってもトイレに行けた。
■ このスレッドは過去ログ倉庫に格納されています