The Container uses optimistic or pessimistic concurrency to control the behavior of multiple transaction accessing the same data.
You can specify this property at entity bean level:
You can specify this property at the table level. NOTE: this is a table-level property:
In this mode Container will allow only one transaction at a time to access the data the Entity Bean is holding. Other transactions that want access to the same data will be blocked (wait) until the first transaction has completed. This is achieved by issuing a tuned SQL with "FOR UPDATE" when Entity Bean is loaded.
The advantage is that the data integrity is maintained as only one transaction is allowed to write at a time.
On the other hand, the performance of the application would suffers significantly because each transaction is blocked for prior one to complete when accessing the same data, which is a severe disadvantage in term of the performance.
No. It is not recommended to use Option A caching when using Pessimistic Concurrency. In Option A mode (i.e. Exclusive Mode), Entity Bean's data is loaded into memory only ONCE. Since Pessimistic Concurrency depends on ejbLoad(), this combination simply won't work.
Pessimistic Concurrency depends on underlying database to support "SELECT ... FOR UPDATE ...". This is defined in SQL Standard and all major Database Vendors support this. Nevertheless, one should check with her/his own Database Documentation.
In Optimistic Concurrency mode, Container allows multiple transactions operate on same data at the same time. While this mode gives good performance, data integrity might be compromised (therefore, Be Careful!)
The main disadvantage is that the data integrity could be compromised if NOT used with caution.
On the other hand, if used appropriately, the advantages are numerous -- it allows multiple transaction to access same data concurrently.
Yes. Optimistic Concurrency only relies on the "WHERE" clause, which is supported by all the RDBMS.
Yes, transaction rollbacks do happen because same data is accessed by multiple transactions. You need to take this into account while designing your application and handle rollbacks by doing retries or some other actions that appropriate in your application domain.
There are three ways to achieve this:
Yes. As mentioned in Option 3 above, you can use 3rd party utilities to write all SQL statement sent to the Database to a separate file. One such utility is P6SPY. You can download this from GitHub.
Follow these steps to install and configure P6SPY: