What is an Optimistic Repeatable Read?

In this isolation level multiple instances of beans are created for each concurrent transaction. When a transaction is committed and when there are any updates in the transaction, a verified update is done. The container validates the state of the cache against the database while committing each transaction.

• If the bean was modified in the transaction, a verified update is performed. The database state is updated with the new values only after ensuring that the data that was read at the start of the transaction is still unmodified in the database.
• If the bean was not modified in the transaction, the container performs a row check with the read state to ensure that no other transaction has modified the instance since the load of the data by this transaction.
• In both cases, if the verified update or row check fails, the transaction is rolled back.
• When two or more transactions happen at the same time, the first transaction is allowed to change the bean and the other transactions are rolled back. In such cases, the application has to retry the transactions. There is no automatic retry mechanism provided by the container.

Use Case Scenario

This concurrency strategy should be used when there are high concurrent reads and low concurrent updates and the cost of rollbacks are sustainable. This strategy yields higher data integrity than Read Committed.

Performance Advantage

For a standalone deployment with exclusive DB access, a load from DB is avoided and concurrent transactions that require shared lock for get accessor methods can go ahead and access the bean.

Related Topics:

• Concurrency types
• Repeatable Read
• Read Committed
• Read Only
• How to setup Concurrency Control for CMP Beans

© Pramati Technologies 2007	Runs on Pramati Server | Feedback | Legal