I´m coming from ejb 2.x and jboss application server. I know that there are different commit-options for the cmp-engine (see below, it´s part of ejb-spec). For example if the container knows that it´s the only one db-user it´s not necessary to synchronize the states of container and db between transactions.

So my question: Is there any similar configuration in hibernate? I´m working on a hibernate/spring-project on tomcat without any ejb/jboss.



The Jboss-EJB commit-options:

Commit option A

The EJB 2.1 spec says: "Option A: The container caches a 'ready' instance between transactions. The container knows that the bean instance has exclusive access to the state of the object in the persistent storage. Therefore, the container does not have to synchronize the instance's state from the persistent storage at the beginning of the next transaction or have to verify that the instance's state is in sync with the persistent storage at the beginning of the next transaction."

Since instances remain in the cache after transaction commits, to use this option, the container must be configured with the global instance cache and commit-option A. And the consequence of global instance cache usage, pessimistic locking is the requirement in this case.

Commit option B

The EJB 2.1 spec says: "The container caches a 'ready' instance between transactions. In contrast to Option A, in this option the instance may not have exclusive access to the state of the object in the persistent storage. Therefore, the container must synchronize the instance's state from the persistent storage at the beginning of the next transaction if the instance's state in the persistent storage has changed. Containers using optimistic concurrency control strategies may instead choose to rollback the transaction if this invariant has not been met: The container must ensure that in order for a transaction to be successfully committed, the transaction must only operate on instance data that is in sync with the persistent storage at the beginning of the transaction."

Like in case of commit option A, instances remain cached after transaction commits, so the container should use global instance cache. Note, that in case of commit option B, when a transaction first time accesses an instance (invokes CMP/CMR getter or setter or another business method) even if the instance is cached its data will be loaded from the database (re-read the spec's quote). So, the cached data is not really used. Except for one case, i.e. when the instance or some of its CMP fields marked as read-only in jbosscmp-jdbc.xml In this case, read-only fields won't be reloaded from the database.

Commit option C

The EJB 2.1 spec says: "The container does not cache a 'ready' instance between transactions. The container returns the instance to the pool of available instances after a transaction has completed."

Instances are evicted from the cache when the transaction is finished (committed or rolled back). In this case eaither global or per-transaction instance cache can be used.

Commit option D

This option is not defined in the spec, it is JBoss-specific option. Commit option D as equivalent to commit option A with the exception that instances are cached for a specific period of time specified in optiond-refresh-rate element (the default value is 30 seconds). For example:

I've got exactly the same question. Any news perhaps ?

I've got a database that is in exclusive use of the application server and I'm getting quite a lot of queries doing dirty checks. It would come in very handy if the application server would know it makes no sense and skip these altogether.