Karen Low wrote:
Thank you very much, JP, for the more detail info!
The web application that I'm working with previously has a huge
deadlock problem, which leads to database hang, application server
(SunONE) also hang, we tune at the DB level, still find the
application server hang at some point (at about 100 concurrent users).
So, I'm checking on the possibility of where has gone wrong .. (I'm
not an experience Java developer yet :) )
On most app servers, under most OS I know of, the maximum concurrent
users that can be handled satisfactorily is around 75-350 (depends on
OS, application, app server, jvm, jdbc driver). You've just found the
breaking point of your application / app server / os combo.
Under Windows Server OSs (Windows 2000, Windows 2003) the OS itself will
hang when there are near 250-300 threads running in my experience. With
Linux, that might go to 400-600. The solution is simply to add more app
servers. Your experience may vary from this, so you should stress test
your deployment environment to know at which load the deployed app
breaks and plan accordingly.
One more question to ask, still referring to the below diagram:
Action class (Servlet):
---> Stateless Session Bean (1)
---> POJO
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (insert)
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (update)
Let's say at some point the DB hangs and throw the exception to SLSB2
and SLSB2 did not do anything but just PrintStackTrace, will the
running thread ever complete in this case?
Yes it should complete its run; if you caught the exception and rolled
back the transaction manually in the catch clause all should be well.
However, your EJBs should always throw exceptions, preferrably
subclasses of RuntimeException; the spec states that when an EJB's
method throws a RuntimeException, the present transaction should be
aborted and the SLSB's instance discarded. That saves you the hassle of
rolling back the transaction manually.
I guess your present code looks like this:
public void slsbMethod() {
try {
//call POJOs
} catch (Exception e) {
//rollback transaction, then print stack trace
e.printStackTrace();
}
}
If it's like the pseudo code above, then the thread will finish
gracefully, and the transaction will be rolled back (manually).
In spite of that, this is a *very* bad programming practice. You could
instead:
public void slsbMethod() throws MyException {
try {
//call POJOs
} catch (Exception e) {
log.error("while doing transactions", e); //using Log4J or other
logging framework
throw new MyException("while doing transactions", e);
}
}
or simply:
public void slsbMethod() throws MyException {
//call POJOs
}
either way, let the Exception propagate upwards into the user interface
so it's handled there instead of sweeping it under the carpet.
Also, use some logging framework instead of printStackTrace; when
handling many concurrent users, just printing the stack trace into the
console isn't enough to track down possible problems, on one hand. On
the other, printStackTrace, and/or any other operation that uses
System.out is really very expensive.
Cause SLSB2 never returns anything once it catches the exception other
than just print the stack trace. If this keep happening, do you think
it's a possibility where it'll make the app server hang?
It depends on what your SLSB2 implementation does, and how it's
deployed. If SLSB2 doesn't throw exceptions, then the same instances are
reused over and over; Does your SLSB initialize some Datasource fields?
do these Datasources/Connections remain initialized after errors? Are
Connections being released promptly when errors arise? How many
instances of SLSB2 are configured to exist in your deployment (pooled &
active)?
My 2c,
JP
===========================================================================
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".
