Hi
I am a great fan of OrionServer generally find it an excellent application
server.
However, lately I have become aware of a fairly serious problem with
OrionServer that I do not know how to solve and may force me to use another
application server. The problem is deadlocking. I am further surprised as to
how little this problem is actually discussed on the mailing lists. Consider
the following code. (Only the important parts are shown.)
I have two identical CMP Entity Beans A and B:
public class ABean implements EntityBean {
*************
.... Some Entity Bean methods and properties not shown.
*************
public int value;
public B b;
public int getValue() {
return this.value;
}
public void setValue(int value) {
this.value = value;
}
public void setB(B b) {
this.b = b;
}
public int getBValue(int i) {
try {
try {
Thread.sleep(20);
} catch (Exception ex) {
}
return b.getValue();
} catch (com.evermind.server.DeadlockException de) {
System.out.println("Catching deadlock exception in A and
rolling back!
Iteration="+i);
throw new EJBException(de);
} catch (Exception ex) {
System.out.println("Catching and throwing other exceptions in
A!");
throw new EJBException(ex);
}
}
}
Bean B is just the reverse of A, i.e. it has a reference on A and has a
method getAValue(int i).
All bean methods have transaction property set to Required. Also,
max-tx-retries="60".
Then I have the following client application C:
..... Some initialization code and then the following loop:
for (int i=0; i<times; i++) {
try {
av = b.getAValue(i);
bv = a.getBValue(i);
System.out.println("it="+i);
} catch (Exception ex) {
ex.printStackTrace();
}
}
If I run more than one instance of C then OrionServer has the following
behavior:
- if exclusive-write-access="false" then one instance of C runs for a while.
After a couple of iterations both instances of C report
com.evermind.server.DeadLockException. After that the entire application
(including OrionServer) just hangs. This Orion freeze-up is not a database
deadlock either.
- if exclusive-write-access="true" then OrionServer instance (not the
clients) reports deadlock exceptions in both instances of A and B. After
that Orion freezes up again.
I got this behavior with 1.5.3 but also for all other versions as far a I
can remember since 1.3.8.
Based on this I have made the following conclusions:
1>OrionServer does not support optimistic caching at all. This is a critical
limitation since you are guaranteed to get deadlock exceptions and Orion
does not provide any way deal with this situation. Retrying just gives
another DeadlockException. Anyway, according to Sun the container is
supposed to deal with deadlocks.
2>There is a serious bug in the implementation of locks on objects. If Orion
freezes up with just two bean instances this just can't be good.
Often the advice given by people to avoid deadlocks is that you should
design your code to avoid deadlocks. In any serious program this is not
really practical. If you have an application with 50 beans, 10 methods each,
you have to design 500 methods so that any combination of 2 of the five
hundred methods will not cause a deadlock, i.e. you have to check for
approximately 125000 combinations of methods to make sure you do not get a
deadlock. Shouldn't the EJB framework have made development more efficient?
I have read somewhere that optimistic caching avoids deadlocks. With
deadlocks in Orion Exceptions are thrown in both threads. With optimistic
caching however, the first thread that modifies an object will always go
through. The other threads get something like a
ConcurrentModificationException. Optimistic caching seems to be more useful
in this aspect.
Am I missing something or is OrionServer still not ready for serious
deployments?
Please help!
Hans Barnard
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.313 / Virus Database: 174 - Release Date: 2002-Jan-02
