The answer is not easy; fortunately, it is vendor-dependent and not in the exam. For those who are interested, read on.
The question that needs to be answered is what is the entity bean's concurrency strategy, meaning how the
EJB container should manage concurrent access to the bean. It determines how and when the container synchronizes its cached copy of the entity with the database. For a server such as WebLogic Server, there are three strategies.
Exclusive Concurrency With exclusive concurrency, the container places an exclusive lock on cached EJB instances when the bean is associated with a transaction. Other requests for the EJB instance are blocked until the transaction completes. Exclusive locks are local to the server instance, so this strategy is most appropriate for a single server architecture. When used in a cluster, exclusive concurrency serializes all requests to a bean instance within a server instance, but concurrency between servers in the cluster that access the same bean concurrently is governed by the database.
Multiple clients can use the exclusive concurrency option to access entity EJBs in a serial fashion. Using this exclusive option means that if two clients simultaneously attempt to access the same entity EJB instance (an instance having the same primary key), the second client is blocked until the EJB is available.
Database Concurrency With database concurrency, concurrency control for an EJB for each transaction is deferred to the underlying datastore. WebLogic Server allocates a separate entity bean instance to each transaction and allows concurrency control to be handled by the database. This is the default option.
With the Database mechanism, the EJB container continues to cache instances of entity bean instances. However, the container does not cache the intermediate state of a bean instance between transactions. Instead, WebLogic Server issues a SQL SELECT for each instance at the beginning of a transaction to obtain the latest EJB data. A SQL UPDATE is issued if there are changes.
The request to commit data is subsequently passed along to the database. The database, therefore, handles all concurrency control and deadlock detection for the EJB's data.
Optimistic Concurrency As with the Database concurrency strategy, Optimistic concurrency gives each transaction its own bean instance. The Optimistic concurrency strategy does not hold any locks in the EJB container or the database while the transaction is in process.
Concurrency strategies present a trade-off between performance and freshness of data. For instance, the Database concurrency strategy carries a risk of deadlock, as each transaction must obtain an update lock from the database. However, you can configure the server to get the database to take out an exclusive lock when the read is done, avoiding the deadlock that can occur when a read lock is upgraded to an exclusive lock. The transaction isolation level can be used in combination with Database concurrency to achieve the desired concurrency behaviour.
And what is the isolation level? A transaction's isolation level is the degree to which it exposes updated but uncommitted data to other transactions. Allowing access to uncommitted data can improve performance, but increases the risk of incorrect data being supplied to other transactions.
Let's look at the definition of the method-level isolation settings for an EJB. If client B's transaction isolation setting is TRANSACTION_READ_COMMITTED, which is supported by just about every
JDBC driver, then it will only be able to view committed reads.
Some drivers support TRANSACTION_READ_UNCOMMITTED. This allows, amongst other things, dirty reads. So, B's transaction would read data which A's transaction had updated but not committed.