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

Looks like the Transaction isolation level set when a transaction is started is applicable only for the database and at the EJB server level it's ignored and always treated as TX_SERIALIZABLE for entity beans.

I understand that like a database row,  an entity bean needs to be locked till the transaction that modified it commits or rollsback. The problem is that a simple read of an attribute results in the locking of the bean till the very end of the transaction which may need to access several other entity beans. All other transactions that needs to invoke a simple read method on the same bean have to wait. In effect a transaction isolation level equivalent to TX_SERIALIZABLE is being forced on all entity beans at the EJB server level. This causes deadlocks at the EJB server level besides being very deterimental to performance when it doesn't cause deadlocks.

 
If the transaction's isolation level is - READ_UNCOMMITTED or  READ_UNCOMMITTED  then other transactions should be able to access the same entity bean simultaneously as long as the bean attributes were only read and not modified. I understand that the problem is in how to determine whether the entity bean attributes were updated or not. But given these transactional ramifications - it looks like  this is critical for being able to use entity beans effectively. So seems to me the the spec should mandate an  isModified feature the way weblogic has and further mandate that it be used to differentiate reads and writes and use the correct transactional isolation level specified in the entity beans deployment descriptor.

Till this is done - it's like working with a database which  ignores the isolation level , doesn't differentiate between reads and writes and always puts exclusive locks for every read. How is everybody dealing with this?  It would be unfortunate to force the EJB development community that wants to use entity beans  to implement this on their own by wrapping all entity beans in java objects which would differentiate reads and writes and prevent locking the entity beans for reads.


Sachin.

Reply via email to