Hatena::ブログ(Diary)

日記

2005-05-15 (日)

CanCam2005年06月号の蛯原友里ちゃん

[][] CanCam 06 月号 エビちゃんベストセレクション 20 03:03

CanCam から,お気に入りの蛯原友里ちゃんを紹介しようというこのコーナー.

今日はモルガンとのタイアップ「思いっきり Sweet & Romantic に♥この夏のヒロインになる!」から P391 の友里ちゃん.

06 月号からはこれガラスとかな.最後は王道といった感じのエビちゃんスマイル♪ パーフェクト (アネッサの CM の解説者風).

そんなわけで (どんなわけで?),やっぱり CanCam 買うしか!!

[][][] 出演予定 TV 番組 03:03

この近辺 (どこ?) で話題のモデルが出演するテレビ番組を分かるだけ掲載します.

新規分は赤字で (レギュラー除く).直近分は太字で.

臼田あさ美
05/16 (月) 深夜 00:20〜00:50 NTV 「歌スタ!!」

[][][] S2Hibernate3 1.0.6b4 22:00

リリースではありません.(^^;

ちょっと Hibernate を触ってみようと思ったのですが,今ならやっぱり Hibernate3 だよね,でもでも S2Hibernate と S2TestCase がないとやる気しないよねってことで,ものすごーーーっく短絡的に S2Hibernate-V1.0.6b4 をベースに Hibernate3 対応してみました.

で,せっかく作ったわけだし,勝手ながら Seasar Sample Project に突っ込んでみました (いいよね?).

S2Hibernate3-V1.0.6b4.zip

サンプルなので [提案] とかはなし♪

正式なのは S2Hibernate コミッタの id:kenichi_okazaki さんが作ってくれることでしょう.


S2Hibernate との主な違いは以下の通り.

  • パッケージを org.seasar.hibernate3 に変更しました.
  • org.hibernate.HibernateExceptionunchecked になったことに伴い,org.seasar.hibernate.HibernateRuntimeException を廃止しました.
  • org.seasar.hibernate.HibernateRuntimeException の廃止に伴い,例外の変換を責務としていた org.seasar.hibernate.S2Session を廃止しました.
  • org.seasar.hibernate.S2Session の廃止により,org.seasar.hibernate3.S2SessionFactoryorg.hibernate.Session を返すように変更しました.
  • org.seasar.hibernate3.interceptor.ReadOnlySessionInterceptororg.hibernate.SessionflushModeNEVER に設定するだけにしました.そして org.seasar.hibernate3.SessionFactoryImpl#beforeCompletion() では Session#getFlushMode()NEVER の場合は Session#flush() を呼び出さないようにしました.

あくまでもサンプルなので,ありのまま提供ということで.

[][] S2.2.9 リリース 21:00

変更内容

  • S2DBCP
    • JTA トランザクションが開始される前にコネクションプールから取得したコネクションを JTA トランザクション中にクローズした場合にコネクションプールに戻されない問題を修正しました (イレギュラーな使い方での問題です).
    • JTA トランザクション中に setAutoCommit(true),commit(),rollback(),setSavePoint() が呼び出された場合に SQLException をスローするように修正しました (「JDBC3.0 Specification」の Chapter 12 「Distributed Transactions」に準拠しました).
  • S2JTA
    • jta.jarjta-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 があったとすると,

  • DB1 prepare → OK
  • DB2 prepare → OK
  • DB3 prepare → OK
  • DB1 commit(2PC)
  • DB2 commit(2PC)
  • DB3 commit(2PC)

ということになります.

「commit(2PC)」は 2 フェーズコミットにおける prepare の後の commit を示します.一方,1 フェーズで行われる通常のコミットを「commit(1PC)」と表記します.


Last Resource Commit Optimization は,このように複数のリソースがある場合に,最後のリソースに対しては prepare ではなく,通常の 1 フェーズコミットを指示するというものです.上の例では

  • DB1 prepare → OK
  • DB2 prepare → OK
  • DB3 commit(1PC)
  • DB1 commit(2PC)
  • DB2 commit(2PC)

ということになります.

もし 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) されます.上の例では

  • DB3 prepare → OK
  • DB2 prepare → OK
  • DB1 commit(1PC)
  • DB2 commit(2PC)
  • DB3 commit(2PC)

ということになります.


Last Resource Commit Optimization のメリットは効率だけではなく,本来 XA に対応していないリソースマネージャでも安全に分散トランザクションに参加することができるようになります.

例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合,最初に HSQLDB からコネクションを取得することで,二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます.

makotanmakotan 2005/05/16 07:00 月曜日だからあさみちゃん!今日はモデル顔無し(笑)歌スタ!!出てるときみたいな感じ

maruo_syunsukemaruo_syunsuke 2005/05/16 13:06 新サンプルヽ(*゜▽゜)ノ バンザーイ