That's
why the spec has the transaction_isolation level so that they can be set
differently for different applications.
The
problem is when the ejb server *forces* TX_SERIALIZABLE level at the
EJB server level when what is specified in the deployment desciptor is
READ_COMMITTED and what is set by the resource manager at the database
level is also READ_COMMITTED.
The issue of whether to use pessimistic locking or
optimistic locking is a trade-off. Pessimistic locking can severely reduce
concurrency in "mostly read-only" and/or "low data
contention" situations. However, optimistic locking suffers from its
own problems, especially in update-intensive applications where data contention
is high. The container ends up doing deep copies of the object graph and
allowing the operations to proceed just to have them fail at commit
time...
In other words, no single solution is right for every application.
Just my two cents,
Robert
In other words, no single solution is right for every application.
Just my two cents,
Robert
