Transaction Isolation

[alice]

Posted on email list w/o success.

The following code hags because it first calls an entity bean instance's method that has "Required" attribute and then calls the same instance's method that has "RequiresNew" attribute. The 1st transaction is blocking the sconde one.

// the following code hangs
class SessionBean {
public void hasRequiredAttribute() {
entityBean.hasRequiredAttribute(); // method 1
// it hangs here !!
entityBean.hasRequiresNewAttribute(); // method 2
}
}

Does JBoss use "pessimistic concurrency" at app server level. My DB (Oracle) has its default isolation level set to READ_COMMITTED. With this isolation level, the above problem should not have occured. How can I determine what isolation level is being implemented in JBoss? Or how can I change that?

And if this is the case, should I ever care about catching TransactionRolledback(Local)Exception occuring in case of "optimistic concurrency"?

[alice]

Will appreciate if someone could reply. Thanks a lot.

[dsundstrom]

This is a classic ejb dealock scenario; you should be getting an ApplicationDeadlockException in JBoss 2.4.5+. If you are not please post a bug report at source forge.

Your session bean method hasRequiredAttribute starts a new transaction or inherits one from the caller. The session bean is locked. You call the entit bean method hasRequiredAttribute which inherits the session bean transaction and locks the entity bean. The entity bean method hasRequiredAttribute but the lock remains until the inherited transaction commits. Then you call the entit bean method hasRequiresNewAttribute, which starts a new transaction and attempts to lock the entity bean. This is the dead lock because entity bean lock is held by the other transaction.

Did you follow?

[alice]

Thanks much for the reply.

1. I don't get any ApplicationDeaqdlockException. How much time should it wait before throwing the transaction?

2. I want to rephrase my question:
I understand that this deadlock is occuring because of the locking u mentioned. But I believe, the app server has an option of implementing "optimistic locking" meaning that it can let >1 transactions go together on the same instance and throw a TxRolledbackException if it detects the other transaction did some work and commited. The way it's behaving now is like it is achieving TRANSACTION_ISOLATION_SERIALIZABLE using "pessimistic locking".

I hope my question is clear.

Thanks much.

[dsundstrom]

Man you are getting out of my area of expertise. Yes the container can implement optimistic locking, but I don't know how much of this JBoss supports. It is rely a question for Bill Burke but I don't think he reads the forums. I suggest you post a question on the jboss-users mailing list.

[alice]

On a different note:

// the following code hangs
class SessionBean {
public void hasRequiredAttribute() {
entityBean.hasRequiredAttribute(); // method 1
// it hangs here !!
entityBean.hasRequiresNewAttribute(); // method 2
}
}

If method 1 above is a read only method, why is the entity bean locked? Shouldn't it allow another transaction from the same thread use the entity bean??

Thanks so much.

[alice]

a different note:

// the following code hangs
class SessionBean {
public void hasRequiredAttribute() {
entityBean.hasRequiredAttribute(); // method 1
// it hangs here !!
entityBean.hasRequiresNewAttribute(); // method 2
}
}

If method 1 above is a read only method, why is the entity bean locked? Shouldn't it allow another transaction from the same thread use the entity bean??

Thanks so much.

[alice]

on a different note:

// the following code hangs
class SessionBean {
public void hasRequiredAttribute() {
entityBean.hasRequiredAttribute(); // method 1
// it hangs here !!
entityBean.hasRequiresNewAttribute(); // method 2
}
}
If method 1 above is a read only method, why is the entity bean locked? Shouldn't it allow another transaction from the same thread use the entity bean??

Thanks so much.

[alice]

on a different note:

// the following code hangs
class SessionBean {
public void hasRequiredAttribute() {
entityBean.hasRequiredAttribute(); // method 1
// it hangs here !!
entityBean.hasRequiresNewAttribute(); // method 2
}
}

If method 1 above is a read only method, why is the entity bean locked? Shouldn't it allow another transaction from the same thread use the entity bean??

Thanks so much.

[bbenton]

alice said:
2. I want to rephrase my question:
I understand that this deadlock is occuring because of the locking u mentioned. But I believe, the app server has an option of implementing "optimistic locking" meaning that it can let >1 transactions go together on the same instance and throw a TxRolledbackException if it detects the other transaction did some work and commited. The way it's behaving now is like it is achieving TRANSACTION_ISOLATION_SERIALIZABLE using "pessimistic locking".
--
What you are describing above is deferring locking and transaction isolation to the database. This can be achieved by specifying Option B concurrency and allowing multiple concurrent entity bean instances per PK. You then need to specify the desired transaction isolation for each transaction (assumably TRANSACTION_SERIALIZABLE based on your earlier comments) in which you do not want to use the database default. This transaction isolation is then passed to the database. If you are using Oracle or PostgreSQL (both use multi-version concurrency control to implement transaction isolation), you would achieve the behavior you described above. If you are using a database that uses locking to implement transaction isolation (Ex. DB2, SQL Server), your results will be different.

Brian Benton
Systems Architect
PowerUp Networks