Re: Transaction isolation level useless at the ejb server level ?

[Robert Patrick]

True, but I don't think many (any?) vendors look at the transaction isolation level to determine their locking/access policies -- most just pass this on to the DBMS.  I suppose that some ODBMS vendors (e.g., GemStone) might have an easier time bringing the transaction isolation level into the container.  Personally, I like the concept but IMHO, I think that the overhead of trying to implement this correctly in an EJB container will outweigh the benefits (especially when you look at the container running in a cluster of EJB servers).

Just my one and a half cents,
Robert

At 12:07 PM 12/7/99 -0800, you wrote:

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