Friday, January 31, 2003 03:19 PM
Yes, standard applications servers handle this well. This is exactly what they were created to do. There is a standard java mail api for sending and reading mail so I'm not sure if you need to use ejbs for this.
We found that stateless session beans and the value object design pattern works best for our application. I can't address this issue without knowing more about your app.
In general, You should not worry about many calls an hour. You should worry about many calls a second. If you follow the J2EE specs: don't create your own threads, don't use file I/O from ejbs, don't use synchronized when implementing ejbs, etc. You can cluster your application when you get to the point where it needs to handle many calls a second.
For the second question. Look at the logging api in jdk1.4. If you can't use jdk1.4 then use log4j which you'll find that the apache.org website. Don't use System.out.println for permanent error messages; just use it for shortterm debug messages when using your debuger is too awkward. If you want to be fancy, you can publish the log messages using JMX and then you can use a JMX monitoring application to handle error notification asynchronously. This is a lot of work but worth the effort if you have a complex application.
We use a coding standard that uses an enter/exit api in our ejbs. We create a base class for all of our ejbs. In the base class we have several method named 'methodEnter(String methodName, Object arg1,
Object arg2, ....)' Each one takes a different number of args. We have a methodExit(String methodName, Throwable t).
For every ejb method, we add a call to methodEnter; before the method ends we call methodExit.
When our application is running at the customer site we can turn on the logging remotely for a specific ejb and see why it is being called and what it is returning.