2005-05-15 (日)
■[Misc][EbiYuri] CanCam 06 月号 エビちゃんベストセレクション 20
CanCam から，お気に入りの蛯原友里ちゃんを紹介しようというこのコーナー．
今日はモルガンとのタイアップ「思いっきり Sweet ＆ Romantic に♥この夏のヒロインになる！」から P391 の友里ちゃん．
06 月号からはこれガラスとかな．最後は王道といった感じのエビちゃんスマイル♪ パーフェクト (アネッサの CM の解説者風)．
そんなわけで (どんなわけで？)，やっぱり CanCam 買うしか！！
■[Misc][TV][スケジュール] 出演予定 TV 番組
この近辺 (どこ？) で話題のモデルが出演するテレビ番組を分かるだけ掲載します．
新規分は赤字で (レギュラー除く)．直近分は太字で．
- 臼田あさ美
- 05/16 (月) 深夜 00:20〜00:50 NTV 「歌スタ！！」
■[Tech][Seasar][Hibernate] S2Hibernate3 1.0.6b4
リリースではありません．(^^;
ちょっと Hibernate を触ってみようと思ったのですが，今ならやっぱり Hibernate3 だよね，でもでも S2Hibernate と S2TestCase がないとやる気しないよねってことで，ものすごーーーっく短絡的に S2Hibernate-V1.0.6b4 をベースに Hibernate3 対応してみました．
で，せっかく作ったわけだし，勝手ながら Seasar Sample Project に突っ込んでみました (いいよね？)．
サンプルなので [提案] とかはなし♪
正式なのは S2Hibernate コミッタの id:kenichi_okazaki さんが作ってくれることでしょう．
S2Hibernate との主な違いは以下の通り．
- パッケージを
org.seasar.hibernate3に変更しました． org.hibernate.HibernateExceptionがuncheckedになったことに伴い，org.seasar.hibernate.HibernateRuntimeExceptionを廃止しました．org.seasar.hibernate.HibernateRuntimeExceptionの廃止に伴い，例外の変換を責務としていたorg.seasar.hibernate.S2Sessionを廃止しました．org.seasar.hibernate.S2Sessionの廃止により，org.seasar.hibernate3.S2SessionFactoryはorg.hibernate.Sessionを返すように変更しました．org.seasar.hibernate3.interceptor.ReadOnlySessionInterceptorはorg.hibernate.SessionのflushModeをNEVERに設定するだけにしました．そしてorg.seasar.hibernate3.SessionFactoryImpl#beforeCompletion()ではSession#getFlushMode()がNEVERの場合はSession#flush()を呼び出さないようにしました．
あくまでもサンプルなので，ありのまま提供ということで．
■[Tech][Seasar] S2.2.9 リリース
変更内容
- S2DBCP
- S2JTA
jta.jarをjta-1_0_1B-classes.zipをリネームしたものに置換しました．- 複数のリソースマネージャ (RDBMS 等) が JTA トランザクションに参加している場合の 2PC における準備 (prepare) フェーズで，あるリソースマネージャが例外をスローした場合に後続のリソースマネージャがロールバックされない問題を修正しました．
- 複数のリソースマネージャ (RDBMS 等) が JTA トランザクションに参加している場合の 2PC における準備 (prepare) フェーズで，最後のリソースマネージャに対しては (2 フェーズではなく) 1 フェーズコミットを行う Last Resource Commit Optimization を実装しました．1 フェーズ コミットするリソースは JTA トランザクションで最初に登録されたされたリソース (通常は最初に取得されたコネクションの接続先 DB) になります．
Last Resource Commit Optimization について
複数のリソースマネージャ (RDBMS 等) が参加した分散トランザクションにおいては，2 フェーズコミットが使用されます．
2フェーズコミットは最初に全てのリソースマネージャに「prepare (準備)」が指示されます．リソースマネージャはトランザクションが確実にコミットできるように整合性制約の違反がないかチェックしたりログへの書き込みを行ったりして肯定の応答をします．
全てのリソースマネージャが prepare に対して肯定の応答を返した場合には，全てのリソースマネージャにトランザクションの commit が指示されます．
もし prepare に対して否定の応答をしたリソースマネージャが一つでもあれば，全てのリソースマネージャに rollback が指示されます．
このように 2 段階の手順を経てトランザクションをコミットするのが 2 フェーズコミットです．
(簡略化して書いてます)
例えば 3 つのリソースマネージャ DB1，DB2，DB3 があったとすると，
ということになります．
「commit(2PC)」は 2 フェーズコミットにおける prepare の後の commit を示します．一方，1 フェーズで行われる通常のコミットを「commit(1PC)」と表記します．
Last Resource Commit Optimization は，このように複数のリソースがある場合に，最後のリソースに対しては prepare ではなく，通常の 1 フェーズコミットを指示するというものです．上の例では
ということになります．
もし DB3 が commit(1pc) に失敗 (rollback) した場合は，prepare に否定の応答をした場合と同様に扱われます．すなわち，DB1 と DB2 は rollback されます．
リソースマネージャに対して prepare と commit(2PC) という 2 回の指示をするよりも commit(1PC) を1回だけ指示する方が効率的 (DBMS 等の処理としても効率的な場合が多いらしい) であるため，Last Resource Commit Optimization と呼ばれます．
S2JTA の実装では，JTA トランザクションに最初に参加したリソースマネージャを 1PC の対象とします．これは通常，トランザクション中で最初に取得されたコネクションの接続先 DB です．実際には，prepare フェーズは JTA トランザクションに参加した順番とは逆順に行われ，最後に残ったりソースマネージャ (最初に参加したりソースマネージャ) が commit(1PC) されます．上の例では
ということになります．
Last Resource Commit Optimization のメリットは効率だけではなく，本来 XA に対応していないリソースマネージャでも安全に分散トランザクションに参加することができるようになります．
例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合，最初に HSQLDB からコネクションを取得することで，二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます．
makotan
2005/05/16 07:00
月曜日だからあさみちゃん！今日はモデル顔無し(笑)歌スタ！！出てるときみたいな感じ
maruo_syunsuke
2005/05/16 13:06
新サンプルヽ(*゜▽゜)ノ バンザーイ