JPA 2.0の新機能 悲観的ロックを試す - しんさんの出張所 はてなブログ編
JPA1.0では楽観的ロックだけ仕様が定義されていた。実際は各プロバイダが独自にヒント等で悲観的ロックを用意していたのだが、それもやっと定義されたために安心して使うことが可能だ。 楽観的ロックはバージョン番号を用意し、トランザクションの開始直前に取得した番号を元に更新にしくというもの。もしそれが存在しない場合、すでに更新されたものとみなし、トランザクションを最初からリトライさせる。 たまに楽観的ロックのようにバージョン番号を利用した値を画面表示時にあらかじめ持っておくといった、アプリケーションでのロックをかけてるところも多いけど、それは楽観的ロックではなく、そういう仕様のアプリケーション。あくまでもトランザクションをどう整合性とるかというだけが楽観的ロックだ。 そもそも更新時にはどのみち行ロック等がかかるわけで。更新方法によってロックがかかる順番が変わることも多いため、デッドロックの可能性
DB操作の“壁”を壊すJPAが起こした「赤壁の戦い」
DB操作の“壁”を壊すJPAが起こした「赤壁の戦い」：現場から学ぶWebアプリ開発のトラブルハック（13）（1/2 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） O/Rマッピングツールは、上手に使えば開発効率を上げることができる、便利なツールです。しかし、データベース（以下、DB）アクセスを隠ぺいしてしまうため、下手に利用するとトラブルの温床になりかねません。本稿では、Java EE 5で採用された標準のDB永続化APIである「JPA（Java Persistence API）」による“悲劇”をお送りします。 「“トラブルハッカー”は神速を尊ぶ」 プルルル、プルルル、午前2時の深夜、不吉な電
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DB2/400 で Java Persistence API (主キーによる SELECT)
