dcsimg
Clarification needed in regards to performance and production quality error handling of j2ee components including jsp, servlets and ejb.
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   JavaDude_S
Posted On:   Friday, January 31, 2003 12:16 AM

If I'm designing a system that uses jsp, for HTML and minor logic control only, servlets for dynamic html generation and EJB wrapping, and of course EJB's for most of the business logic, what are the best ways in creating components, for instance an email capable components which could have many calls made to it every hour, when using this design without using, say, RMI. Should this type of functionality be handled in a Stateless Session bean? Or should a servlet be used. I'm thinking about the costs and the need for multiple threads which are imperative to think about in a case like this but do standard application servers handle this well? Another question , which seems to be starting big debates among fellow programmers, is what is    More>>


If I'm designing a system that uses jsp, for HTML and minor logic control only, servlets for dynamic html generation and EJB wrapping, and of course EJB's for most of the business logic, what are the best ways in creating components, for instance an email capable components which could have many calls made to it every hour, when using this design without using, say, RMI. Should this type of functionality be handled in a Stateless Session bean? Or should a servlet be used. I'm thinking about the costs and the need for multiple threads which are imperative to think about in a case like this but do standard application servers handle this well?



Another question , which seems to be starting big debates among fellow programmers, is what is the best way for maintenance and performance for implementing a error handling mechanism in a j2ee aplication? Now we all know that we use try, catch, and finally but as far as storing errors and presenting a 'user friendly' error to the end user, which is the most practiced and most efficient way of dealing with it? Some say just use System.out.println in your catch section and some say to write a proprietary API that writes the stack trace to an error file on the hard drive. Does this mean it needs to be presented in every try, catch and finally section in the application which could be of any size.



Thank you all for any input you can give me, I want to start this project in the right direction.

Jacob

   <<Less

Re: Clarification needed in regards to performance and production quality error handling of j2ee components including jsp, servlets and ejb.

Posted By:   Software_Framework  
Posted On:   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.

About | Sitemap | Contact