Sachin Aggarwal wrote:
> 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.
Yes, the server does not DO anything itself - it only passes the information to
resource managers (note that this feature seems to have been dropped in the 1.1
spec)
> I understand that like a database row, an entity bean needs to be locked till
> the transaction that modified it commits or rollsback.
Not so. Two transactions concurrently accessing the same logical entity bean
instance will get two in-memory copies of the instance. If both transactions
have update intent on the instance, then it depends on the database locking
strategy (optimistic or pessimistic) whether concurrent access is allowed. In no
case are two threads EVER running through the same in-memory instance of an EJB.
> 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.
Not so - because there can be multiple in-memory instances.
> 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.
READ_UNCOMMITTED is unlikely to be what you want. The effect you are looking for
is normal READ under optimistic concurrency control. This READ can obtain the
before-data that an in-flight update transaction has modified.
> 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.
Not so, as I hope I've made clear above.
Ian McCallion
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
