J2EE Overview

J2EE Servlet 1

J2EE Servlet 2










J2EE Best Practices

J2EE Logging

J2EE Testing

J2EE Deployment

J2EE Development Process

J2EE Best Practices Interview Questions

Give some tips on J2EE application server performance tuning ?

  • Set the Web container threads, which will be used to process incoming HTTP requests. The minimum size should be tuned to handle the average load of the container and maximum should be tuned to handle the peak load. The maximum size should be less than or equal to the number of threads in your Web server.
  • Application servers maintain a pool of JDBC resources so that a new connection does not need to be created for each transaction. Application servers can also cache your prepared statements to improve performance. So you can tune the minimum and maximum size of these pools.
  • Tune your initial heap size for the JVM so that the garbage collector runs at a suitable interval so that it does not cause any unnecessary overhead. Adjust the value as required to improve performance.
  • Set the session manager settings appropriately based on following guidelines:
  • Set the appropriate value for in memory session count.
  • Reduce the session size.
  • Don’t enable session persistence unless required by your application.
  • Invalidate your sessions when you are finished with them by setting appropriate session timeout.
  • Calls to EJB from a separate JVM are handled by ORB (Object Request Broker). ORB uses a pool of threads to handle these requests. The thread pool size should be set appropriately to handle average and peak loads.
  • If a servlet or JSP file is called frequently with identical URL parameters then they can be dynamically cached to improve performance.
  • Turn the application server tracing off unless required for debugging.
  • Some application servers support lazy loading and dirty marker strategies with EJB to improve performance.

    Explain some of the J2EE best practices ?

  • Recycle your valuable resources by either pooling or caching. You should create a limited number of resources and share them from a common pool (e.g. pool of threads, pool of database connections, pool of objects etc). Caching is simply another type of pooling where instead of pooling a connection or object, you are pooling remote data (database data) and placing it in the memory (using Hashtable etc).
  • Avoid embedding business logic in a protocol dependent manner like in JSPs, HttpServlets, Struts action classes etc. This is because your business logic should be not only executed by your Web clients but also required to be shared by various GUI clients like Swing based stand alone application, WAP clients etc.
  • Automate the build process with tools like Ant, CruiseControl, and Maven etc. In an enterprise application the build process can become quite complex and confusing.
  • Build test cases first (i.e. Test Driven Development (TDD), refer section Emerging Technologies) using tools like JUnit. Automate the testing process and integrate it with build process.
  • Separate HTML code from the Java code: Combining HTML and Java code in the same source code can make the code less readable. Mixing HTML and scriptlet will make the code extremely difficult to read and maintain. The display or behavior logic can be implemented as a custom tags by the Java developers and Web designers can use these Tags as the ordinary XHTML tags.
  • It is best practice to use multi-threading and stay away from single threaded model of the servlet unless otherwise there is a compelling reason for it. Shared resources can be synchronized or used in read-only manner or shared values can be stored in a database table. Single threaded model can adversely affect performance.
  • Apply the following JSP best practices:
  • Place data access logic in JavaBeans: The code within the JavaBean is readily accessible to other JSPs and Servlets.
  • Factor shared behavior out of Custom Tags into common JavaBeans classes: The custom tags are not used outside JSPs. To avoid duplication of behavior or business logic, move the logic into JavaBeans and get the custom tags to utilize the beans.
  • Choose the right "include" mechanism:
  • Use style sheets (e.g. css), template mechanism (e.g. struts tiles etc) and appropriate comments (both hidden and output comments).
  • Use the J2EE standard packaging specification to improve portability across Application Servers.
  • Use proven frameworks like Struts, Spring, Hibernate, JSF etc.
  • Apply appropriate proven J2EE design patterns to improve performance and minimize network communications cost (Session façade pattern, Value Object pattern etc).
  • Batch database requests to improve performance.
    For example
    Connection con = DriverManager.getConnection("").
    Statement stmt = con.createStatement().
    stmt.addBatch("INSERT INTO Address....);
    stmt.addBatch("INSERT INTO Contact....);
    stmt.addBatch("INSERT INTO Personal");
    int[] countUpdates = stmt.executeBatch();

    Use "PreparedStatements" instead of ordinary "Statements" for repeated reads.
  • Avoid resource leaks by
  • Closing all database connections after you have used them.
  • Cleaning up the objects after you have finished with them especially when an object having a long life cycle refers to a number of objects with short life cycles, then you have the potential for memory leak.
  • Having the resource (i.e. database connections, statements, etc) clean up code in a finally {} block, which is always executed, even if an exception is thrown.
  • Handle and propagate exceptions correctly. Decide between checked and unchecked (i.e. RunTime) exceptions.

    Explain some of the J2EE best practices to improve performance ?

    In short, manage valuable resources wisely and recycle them where possible, minimize network overheads and serialization cost, and optimize all your database operations.
  • Manage and recycle your valuable resources by either pooling or caching. You should create a limited number of resources and share them from a common pool (e.g. pool of threads, pool of database connections, pool of objects etc). Caching is simply another type of pooling where instead of pooling a connection or object, you are pooling remote data (database data), and placing it in memory (using Hashtable etc). Unused stateful session beans must be removed explicitly and appropriate idle timeout should be set to control stateful session bean life cycle.
  • Use effective design patterns to minimize network overheads (Session facade, Value Object etc, use of fast-lane reader pattern for database access. Caching of retrieved JNDI InitialContexts, factory objects (e.g. EJB homes) etc. using the service locator design pattern, which reduces expensive JNDI access with the help of caching strategies.
  • Minimize serialization costs by marking references (like file handles, database connections etc), which do not require serialization by declaring them "transient". Use pass-by-reference where possible as opposed to pass by value.
  • Set appropriate timeouts: for the HttpSession objects, after which the session expires, set idle timeout for stateful session beans etc.
  • Improve the performance of database operations with the following tips:
  • Database connections should be released when not needed anymore, otherwise there will be potential resource leakage problems.
  • Apply least restrictive but valid transaction isolation level.
  • Use JDBC prepared statements for overall database efficiency and for batching repetitive inserts and updates. Also batch database requests to improve performance.
  • When you first establish a connection with a database by default it is in auto-commit mode. For better performance turn auto-commit off by calling the connection.setAutoCommit(false) method.
  • Where appropriate (you are loading 100 objects into memory but use only 5 objects) lazy load your data to avoid loading the whole database into memory using the virtual proxy pattern. Virtual proxy is an object, which looks like an object but actually contain no fields until when one of its methods is called does it load the correct object from the database.
  • Where appropriate eager load your data to avoid frequently accessing the database every time over the network.

    How do you identify a Java process id in a UNIX machine ?

    $> ps -def | grep java

    How do you get a thread dump of a Java process in a UNIX machine ?

    $> kill -3

    If you have multiple java processes running in a UNIX machine, how would you identify a particular process ?

    $> /usr/ucb/bin/ps auxwww | grep java | grep

    What tools/commands do you use to help you identify an out of control Java process in a UNIX machine ?

    UNIX stat tools/commands like jvmstat, vmstat, iostat etc.

    How would you display the number of active established connections to localhost in a UNIX machine ?

    $> netstat -a | grep EST

    How do you find out drive statistics in a UNIX machine ?

    $> iostat -E

    J2EE Logging Interview Questions >>>

    Home Clouds