そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

3.4 Optimistic Locking and Concurrency

勉強がてら、JSR-220を読んで行こうかと思います。間違っていれば、つっこみお願いします。

This specification assumes the use of "optimistic locking".

この仕様は、「楽観的ロック」の使用を扱います。

It assumes that the databases to which persistence units are mapped will be accessed by implementations using read-committed isolation (or a vendor equivalent in which long-term read locks are not held), and that writes to the database typically occur only when the flush method has been invoked―whether explicitly by the application, or by the persistence provider runtime in accordance with the flush mode setting.

トランザクション分離のタイプはread-committedを想定。
データベースに書き込みが行われるのは、アプリケーションで明示的にflushメソッドを呼び出したときか、flushモードの設定にしたがって、パーシステンス・プロバイダにflushメソッドが呼び出されたときだけ。

If a transaction is active, a compliant implementation of this specification is permitted to write to the database immediately (i.e., whenever a managed entity is updated, created, and/or removed), however, the configuration of an implementation to require such non-deferred database writes is outside the scope of this specification.

もし、トランザクションがアクティブならば(ちょっと良く理解できてません)、この仕様を素直に実装すると、エンティティに何かしらの操作があった時に、データベースにすぐに書き込みして良いことになる。でもその辺は、使用の範囲外ですよ、と。

The configuration of the setting of optimistic lock modes is described in section 3.4.3.

楽観的なロックモードのセッティングの構成は、セクション3.4.3説明しますよ。

Applications that prefer the use of pessimistic locking may require that database isolation levels higher than read-committed be in effect. The configuration of the setting of such database isolation levels, however, is outside the scope of this specification.

悲観的ロックを使用するアプリケーションは、read-committedよりも、高度なデータベース分離レベルを必要としているのかもしれないけど、そんなことはこの仕様の範囲外です。