-
1. Re: Transaction Isolation
alice Jun 30, 2002 2:33 AM (in response to alice)Will appreciate if someone could reply. Thanks a lot.
-
2. Re: Transaction Isolation
dsundstrom Jun 30, 2002 3:03 PM (in response to alice)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? -
3. Re: Transaction Isolation
alice Jul 1, 2002 8:49 PM (in response to 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. -
4. Re: Transaction Isolation
dsundstrom Jul 2, 2002 5:57 PM (in response to alice)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.
-
5. Re: Transaction Isolation
alice Jul 9, 2002 6:21 PM (in response to 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. -
6. Re: Transaction Isolation
alice Jul 9, 2002 6:22 PM (in response to 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. -
7. Re: Transaction Isolation
alice Jul 9, 2002 6:23 PM (in response to 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. -
8. Re: Transaction Isolation
alice Jul 9, 2002 6:25 PM (in response to 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. -
9. Re: Transaction Isolation
bbenton Jan 20, 2003 10:27 AM (in response to alice)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