2006-01-09
S2JMS-Container 向けのメモ． S2JMS-Container を使った受信メッセージ処理におけるトランザクション境界は，JMS メッセージをトランザクショナルに受信するかどうかの設定で異なります． トランザクショナルにメッセージを受信する場合，トランザクション境界は S2JCA が設定します． S2JMS-Container の MessageListener#onMessage(Message) はトランザクション境界の中で呼び出されます． ただし，S2JMS-Container 上のアプリケーションはこのトランザクション境界を前提にせず，DB アクセス等を行うなら適切なところに j2ee.txRequired 等のインターセプタを設定した方がいいと思います． 非トランザクショナルにメッセージを受信する場合，S2JCA はトランザクション制御を行いません． S2JMS-C
2006-01-03
WorkManager の簡単な実装が概ね終了． 「簡単な実装」というのはスレッドプールをきめ細かく制御とかしていないため．例えばスレッドのプライオリティとか，スレッドプールにリクエストするキューの最大長を設定したりプライオリティキューにしたりなどなど． 大がかりなアプリケーションサーバならこの辺もちゃんとしないといけないのかもしれませんが，スタンドアロンな S2JMS-Container での利用を前提にするならあまり必要な状況にはならないような気のせいが． そんなわけで (どんなわけで？)，概ね終了． 「概ね終了」ということはまだ終了には至っていないわけですが，その大きなものが javax.resource.spi.work.ExecutionContext のサポート．これがやっかいなんですよ． ExecutionContext というのは，リソースアダプタが受信したメッセージをワー
2006-01-14
変更しますた． これまで S2JCA は org.seasar.jca の後に，cm とか mi，lm，wm といった短い名前を使っていました． これらはそれぞれ，Connection Management，Message Inflow，Lifecycle Management，Work Management の略称です． これは JCA 仕様の「16. API Requirements」に出てくる由緒正しい略称なのですが，いかんせん短すぎて自分でも分からなくなりそうな気配濃厚． そんなわけで (どんなわけで？)，気持ち長めに変更しました． カテゴリ 旧 新 Connection Management cm outbound Message Inflow mi inbound Lifecycle Management lm lifecycle Work Management wm work
2005-03-26
java.lang.reflect パッケージに AccessibleObject というクラスがあります．こいつは同パッケージの Field や Method，Constructor のスーパークラスです． これらに対して setAccessible(true) してあげると，private なフィールドにアクセスしたり，private なメソッドやコンストラクタを呼び出したりできます．final なフィールドを更新したりもできるらしいけれどやったことはありません． こいつらの使い方がちょっと悩ましいので書いてみるテスト． まず，Method なんかのインスタンスを取得するには Class のインスタンスが必要です．あるクラスを表現する Class のインスタンスは，クラスローダごとに一つだけです． そして，あるクラスのあるメソッドを表現する Method のインスタンスも (クラスロー
2008-12-04 - 業務連絡 2 フェーズコミットと Logging Last Resource，特許とオープンソース
しました． ■変更点 2.4.32 からの変更点は次のとおりです． Bug [CONTAINER-299] - [S2JDBC] SimpleWhere や Operations の starts()/ends()/contains() で，Oracle ではワイルドカードになる全角の '％' や '＿' がエスケープされない問題を修正しました．[Seasar-user:16239] [CONTAINER-300] - [S2BeanUtils] CharSequence型指定時にexcludesメソッドが利かない不具合を修正しました。 [CONTAINER-302] - [JPA] Jar ファイル内の永続ユニットを扱うと FileNotFoundException が発生する問題を修正しました．[Seasar-user:16276] [CONTAINER-312] - [S2JDBC]
SSD とストレージの将来 - kazuhoのメモ置き場
SQL に痛痒感を感じる日々を過ごしている身としては、RDBMS がレガシーだというのは、まったく同感ですが。 SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。 2008-12-12 そんなことないと思います。理由は以下の２点。 フラッシュの書き換えブロックサイズは数キロバイト以上 トランザクションは意識して実装せざるを得ない フラッシュメモリはランダムリードできますが、DRAM のようにランダムライトできるわけではありません。書き込みが非常に遅いのに加えて書き換え回数の制限もあるので、メインメモリと同様のプログラム手法を使うのは難しいと思います。 次にトランザクションについてですが、組み込み型データベースとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.wikiroom.com/koichik/?JCA%20%C6%FE%CC%E7%B5%AD