国産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/
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:47Rails使ったことないんだけど、
Railsはどのあたりが本質的で面白いか聞きたいのだけど、、、。
0174デフォルトの名無しさん
2009/05/25(月) 19:12:26排他バカにみんな呆れて、過疎ってきた
0175デフォルトの名無しさん
2009/05/26(火) 00:31:44あと更新に失敗したら再度トランザクションやりなおしさせる処理が抜けてるシステムも多い
楽観的ロックは開発者に負担を強いるからね
0176デフォルトの名無しさん
2009/05/26(火) 00:41:320177デフォルトの名無しさん
2009/05/26(火) 01:26:320178デフォルトの名無しさん
2009/05/26(火) 03:25:49更新用データ取得時にバージョンカラムの値も取得しておいて
画面上ではhidden値にでも入れておいて
更新するときのBeanにその値を詰めておくだけだろ
アップデート文はFWが自動発行してくれるんだし
この程度を負担とか言っていたら、何も任せられないよ
0179デフォルトの名無しさん
2009/05/26(火) 08:16:32負担ってのはどう考えても更新失敗時の例外処理の面倒さだろ。
0180デフォルトの名無しさん
2009/05/26(火) 13:34:250181デフォルトの名無しさん
2009/05/26(火) 13:54:48悲観的ロックというのは、その画面を誰かが開いている間、
ロックテーブルとかにレコードを入れて、他のユーザは強制的に入れないようにするような手法だと思っています。
0182デフォルトの名無しさん
2009/05/26(火) 18:26:02後はさ、ユーザーに最終更新日によって確認してもらうのがいいよね。
楽観的ロックでもさ、多数のユーザーが同時に同じ操作を行った際には、
エラーメッセージによって、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更新時には悲観的ロックかもしれない
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見て思った。腑に落ちた
■ このスレッドは過去ログ倉庫に格納されています