JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

The following pages have their detailed tips extracted below

• Balancing Network Load with Priority Queues
• Detailed article on load testing systems
• J2EE Application server performance
• Designing Entity Beans for Improved Performance
• Paper detailing the "Best Practices for Developing High Performance Web and Enterprise Applications" using IBM's WebSphere
• J2EE worst practices
• Weblogic tuning (generally applicable Java tips extracted)
• J2EE Performance tuning
• Design patterns catalog
• EJB design
• Design Patterns
• Performance tuning
• Why CMP is better than BMP
• Scalable recoverable applications
• Stateful to Stateless Bean
• J2EE design patterns to improve performance
• Performance optimizing design patterns for J2EE
• Article on recycling resource pools
• EJB performance tips
• Pattern performance tips
• Sun Community chat on Java BluePrints
• Clustering with JBoss
• Performance chapter (chapter 20) from "Professional JSP 2nd Edition"
• Sun community chat on EJBs with Pravin Tulachan
• J2EE best practices.
• Rules and Patterns for Session Facades
• EJBs are wonderful
• EJB performance tips
• Local entity beans
• J2EE challenges
• EJB Clustering
• J2EE Application servers
• Moving from JSP to EJB
• Judging various aspects of Java, including performance
• JMS vs RMI
• Clustering for J2EE and Java application servers
• Various strategies for connecting to databases
• HTTP sessions vs
• Server performance testing
• Optimizing entity beans
• EJB best practices
• J2EE clustering
• Avoiding memory leaks in EJBs
• "EJB2 clustering with application servers"
• RMI arguments
• Choosing a J2EE application server, emphasizing the importance of performance issues
• Implementing clustering on a J2EE web server (JBoss+Jetty)
• EJB2.0 Container-Managed Persistence
• Architecting and Designing Scalable, Multitier Systems
• Sun community discussion on "Optimizing Entity Beans" with Akara Sucharitakul
• Optimizing dynamic web pages
• Stateful vs Stateless EJBs
• Deciding whether EJB is appropriate.

The following detailed tips have been extracted from the raw tips page

http://www.ddjembedded.com/resources/articles/2001/0112g/0112g.htm
Balancing Network Load with Priority Queues (Page last updated December 2001, Added 2002-02-22, Author Frank Fabian, Publisher Dr. Dobb's). Tips:

• [Note that Java application servers often do not show a constant service time. Instead the service time often increases with higher concurrency due to non-linear effects of garbage collection].

http://www.javareport.com/html/from_pages/article.asp?id=252
Detailed article on load testing systems (Page last updated January 2001, Added 2001-01-19, Author Himanshu Bhatt, Publisher Java Report). Tips:

• Logging and stateful EJB can degrade performance.

http://www.sys-con.com/java/article.cfm?id=671
J2EE Application server performance (Page last updated April 2001, Added 2001-04-20, Author Misha Davidson, Publisher Java Developers Journal). Tips:

• Good performance has sub-second latency (response time) and hundreds of (e-commerce) transactions per second.
• For read-only queries involving large amounts of data, avoid EJB objects and use JavaBeans as an intermediary to access manipulate and store the data for JSP access.
• Use stateless session EJBs to cache and manage infrequently changed data. Update the EJB occasionally.
• Use a dedicated session bean to perform and cache all JNDI lookups in a minimum number of requests.

http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/
Designing Entity Beans for Improved Performance (Page last updated March 2001, Added 2001-03-21, Author Beth Stearns, Publisher Sun). Tips:

• Remember that every call of an entity bean method is potentially a remote call.
• Designing with one access method per data attribute should only be used where remote access will not occur, i.e. entities are guaranteed to be in the same container.
• Use a value object which encapsulates all of an entity's data attributes, and which transfers all the data in one network transfer. This may result in large objects being transferred though.
• Group entity bean data attributes in subsets, and use multiple value objects to provide remote access to those subsets.

http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Paper detailing the "Best Practices for Developing High Performance Web and Enterprise Applications" using IBM's WebSphere. All the tips are generally applicable to servlet/EJB development, as well as other types of server development. (Page last updated September 2000, Added 2001-01-19, Author Harvey W. Gunther, Publisher IBM). Tips:

• Access entity beans from session beans, not from client or servlet code.
• Reuse EJB homes.
• Use Read-Only methods where appropriate in entity-beans to avoid unnecessary invocations to store.
• The EJB "remote programming" model always assumes EJB calls are remote, even where this is not so. Where calls are actually local to the same JVM, try to use calling mechanisms that avoid the remote call.
• Remove stateful session beans (and any other unneeded objects) when finished with, to avoid extra overheads in case the container needs to be passivated.
• Beans.instantiate() incurs a filesystem check to create new bean instances. Use "new" to avoid this overhead.

http://www.onjava.com/pub/a/onjava/2002/04/03/javaenterprise_tips.html
J2EE worst practices (Page last updated April 2002, Added 2002-04-26, Author Brett McLaughlin, Publisher OnJava). Tips:

• Stateless session beans are soooo much faster.

http://www.weblogic.com/docs51/admindocs/tuning.html
Weblogic tuning (generally applicable Java tips extracted) (Page last updated June 2000, Added 2001-03-21, Author BEA Systems, Publisher BEA). Tips:

• Try to avoid excessive cycling (creation/deletion or activation/passivation) of beans.

http://www.sys-con.com/java/article.cfm?id=1171
J2EE Performance tuning (Page last updated October 2001, Added 2001-10-22, Author James McGovern, Publisher Java Developers Journal). Tips:

• Always access entity beans from session beans.
• If only using an entity bean for data access, use JDBC directly instead.
• Use read-only in the deployment descriptor.
• Cache access to EJB homes.
• Use local entity beans when beans are co-located in the same JVM.
• Proprietary stubs can be used for caching and batching data.
• Use a dedicated remote object to generate unique primary keys.

http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html
Design patterns catalog (Page last updated 2001, Added 2002-01-25, Author ?, Publisher Sun). Tips:

• [Page lists some patterns with summaries and links to detailed info. Patterns are: Data Access Object; Fast-Lane Reader; Front Controller; Page-by-Page Iterator; Session Facade; Value Object].
• Use the Data Access Object pattern to decouple business logic from data access logic, allowing for optimizations to be made in how data is managed.
• Use the Fast-Lane Reader pattern to accelerate read-only data access by not using enterprise beans.
• Use the Front Controller pattern to centralize incoming client requests, allowing optimizations to be made in aggregating the resulting view.
• Use the Page-by-Page Iterator pattern to efficiently access a large, remote list by retrieving its elements one sublist of value objects at a time.
• Use the Session Facade pattern to provide a unified, workflow-oriented interface to a set of enterprise beans, thus minimizing client calls to server EJBs.
• Use the Value Object pattern to efficiently transfer remote, fine-grained data by sending a coarse-grained view of the data.

http://www.sys-con.com/java/article.cfm?id=1268
EJB design (Page last updated January 2002, Added 2002-01-25, Author Boris Lublinsky, Publisher Java Developers Journal). Tips:

• Some application server implementations (e.g., WebSphere) automatically convert remote communications to local communications to make them faster.
• Low granularity (i.e. fine-grained) methods in an EJB typically leads to poor performance of the overall system.
• Local interfaces in EJB 2.0 is one attempt to improve overall performance: local interfaces provide for beans in the same container to interact locally without involving RMI.
• The most effective way to improve the overall performance of EJB-based applications is to minimize the amount of method invocations, making the communications overhead negligible compared with the execution time. This can be achieved by implementing coarse-grained methods.
• Entity beans should not be simply mapped to database tables. Treating entity beans as such fine-grained objects which are effectively wrappers on table rows leads to increased network communications and heavier database communications than if entity beans are treated as coarse-grained components.
• For optimal performance, entity beans should be designed to: have large granularity, which usually means they should contain multiple Java classes and support multiple database tables; be associated with a certain amount of persistent data, typically multiple database tables, one of which should define the primary key for the whole bean; support meaningful business methods and encapsulate business rules to access the data.
• Don't use client transactions in the EJB environment since long-running transactions that can cause database lockup.
• Entity beans are transactional resources due to their stateful nature, but application server vendors often rely on the underlying database to lock and resolve access appropriately. Although this approach greatly improves performance, it provides the potential for database lockup.

http://developer.java.sun.com/developer/technicalArticles/J2EE/despat/
Design Patterns (Page last updated January 2002, Added 2002-01-25, Author Vijay Ramachandran, Publisher Sun). Tips:

• [Article discusses several design patterns: Model-View-Controller, Front Controller, Session Facade, Data Access Object].
• Use the Front Controller pattern to channel all client requests through a single decision point, which allows the application to be balanced at runtime.
• Use a Session Facade to provide a simple interface to a complex subsystem of enterprise beans, and to reduce network communication requirements.
• Use Data Access Objects to decouple the business logic from the data access logic, allowing data access optimizations to be decoupled from other types of optimizations.

http://www.sys-con.com/java/article.cfm?id=1149
Performance tuning (Page last updated September 2001, Added 2001-10-22, Author James McGovern, Publisher Java Developers Journal). Tips:

• Avoid stateful sessions.

http://www.sys-con.com/weblogic/article.cfm?id=58
Why CMP is better than BMP (Page last updated April 2002, Added 2002-04-26, Author Tyler Jewell, Publisher Weblogic Developers Journal). Tips:

• Use CMP except in specific cases when BMP is necessary: fields use stored procedures; persistence is not simple JDBC (e.g. JDO); One bean maps to multiple tables; non-standard SQL is used.
• CMP can make many optimizations: optimal locking; optimistic transactions; efficient lazy loading; efficiently combining multiple queries to the same table (i.e. multiple beans of the same type can be handled together); optimized multi-row deletion to handle deletion of beans and their dependents.

http://www.theserverside.com/resources/article.jsp?l=Building-Sclable-Recoverable-Applications
Scalable recoverable applications (Page last updated May 2002, Added 2002-07-24, Author Billy Newport, Publisher The Server Side). Tips:

• A database caching layer in the servlet helps performance. An EJB caching layer is difficult to achieve.

http://www.onjava.com/pub/a/onjava/excerpt/bldgjavaent_8/index3.html
Stateful to Stateless Bean (Page last updated February 2002, Added 2002-03-25, Author Brett McLaughlin, Publisher OnJava). Tips:

• Stateless session beans are much more efficient than stateful session beans.
• Stateless session bean have no state. Most containers have pools of stateless beans. Each stateless bean instance can serve multiplw clients, so the bean pool can be kept small, and doesn't need to change in size avoiding the main pooling overheads.
• A separate stateful bean instance must exist for every client, making bean pools larger and more variable in size.
• [Article discusses how to move a stateful bean implementation to stateless bean implementtaion].

http://www.javaworld.com/javaworld/javaone01/j1-01-patterns.html
J2EE design patterns to improve performance (Page last updated June 2001, Added 2001-06-18, Author Daniel H. Steinberg, Publisher JavaWorld). Tips:

• Combine multiple remote calls for state information into one call using a value object to wrap the data (the Value Object pattern, superceded by local interfaces in EJB 2.0).

http://developer.java.sun.com/developer/technicalArticles/J2EE/J2EEpatterns/
Performance optimizing design patterns for J2EE (Page last updated December 2001, Added 2001-12-26, Author Vijay Ramachandran, Publisher Sun). Tips:

• For read-only access to a set of data that does not change rapidly, use the Fast Lane Reader pattern which bypasses the EJBs and uses a (possibly non-transactional) data access object which encapsulates access to the data. Use the Fast Lane Reader to read data from the server and display all of them in one shot.
• When you need to access a large remote list of objects, use the Page-by-Page Iterator pattern which sends smaller subsets of the data as requested until the client no longer want any more data. Use the Page-by-Page Iterator to send lists of simple objects from EJBs to clients.
• When the client would request many small data items which would require many remote calls to satisfy, combine the multiple calls into one call which results in a single Value Object which holds all the data required to be transferred. Use the Value Object to send a single coarse-grained object from the server to the client(s).

http://www.javaworld.com/javaworld/javatips/jw-javatip78.html
Article on recycling resource pools (Page last updated 1998, Added 2000-12-20, Authors Philip Bishop and Nigel Warren, Publisher JavaWorld). Tips:

• Use the builder pattern: break the construction of complex objects into a series simpler Builder objects, and a Director object which combines the Builders to form the complex object. Then you can use Recycler (a type of Director) to replace only the broken parts of the complex object, so reducing the amount of objects that need to be recreated.

http://www.precisejava.com/javaperf/j2ee/EJB.htm
EJB performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

• EJB calls are expensive. A method call from the client could cover all the following: get Home reference from the NamingService (one network round trip); get EJB reference (one or two network roundtrips plus remote creation and initialization of Home and EJB objects); call method and return value on EJB object (two or more network rountrips: client-server and [mutliple] server-db; several costly services used such as transactions, persistence, security, etc; multiple serializations and deserializations).
• If you don't need EJB services for an object, use a plain Java object and not an EJB object.
• Use Local interfaces (from EJB2.0) if you deploy both EJB Client and EJB in the same JVM. (For EJB1.1 based applications, some vendors provide pass-by-reference EJB implementations that work like Local interfaces).
• Wrap multiple entity beans in a session bean to change multiple EJB remote calls into one session bean remote call and several local calls (pattern called SessionFacade).
• Change multiple remote method calls into one remote method call with all the data combined into a parameter object.
• Control serialization by modifying unnecessary data variables with 'transient' key word to avoid unnecessary data transfer over network.
• Cache EJBHome references to avoid JNDI lookup overhead (pattern called ServiceLocator).
• Declare non-transactional methods of session beans with 'NotSupported' or 'Never' transaction attributes (in the ejb-jar.xml deployment descriptor file).
• Transactions should span the minimum time possible as transactions lock database rows.
• Set the transaction time-out (in the ejb-jar.xml deployment descriptor file).
• Use clustering for scalability.
• Tune the EJB Server thread count.
• Use the HttpSession object rather than a Stateful session bean to maintain client state.
• Use the ECperf benchmark to help differentiate EJB server performances.
• Tune the Stateless session beans pool size to minimize the creation and destruction of beans.
• Use the setSessionContext() or ejbCreate() method to cache bean specific resources. Release acquired resources in the ejbRemove() method.
• Tune the Stateful session beans cache size to and time-out minimize activations and passivations.
• Allow stateful session beans to be removed from the container cache by explicitly using the remove() method in the client.
• Tune the entity beans pool size to minimize the creation and destruction of beans.
• Tune the entity beans cache size to minimize the activation and passivation of beans (and associated database calls).
• Use the setEntityContext() method to cache bean specific resources and release them from the unSetEntityContext() method.
• Use Lazy loading to avoid unnecessary pre-loading of child data.
• Choose the lowest cost transaction isolation level that avoids corrupting the data. Transaction levels in increasing cost are: TRANSACTION_READ_UNCOMMITED, TRANSACTION_READ_COMMITED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE.
• Use the lowest cost locking available from the database that is consistent with any transaction.
• Create read-only entity beans for read only operations.
• Use a dirty flag where supported by the EJB server to avoid writing unchanged EJBs to the database.
• Commit the data after the transaction completes rather than after each method call (where supported by EJB server).
• Do bulk updates to reduce database calls.
• Use CMP rather than BMP to utilize built-in performance optimization facilities of CMP.
• Use ejbHome() methods for global operations (from EJB2.0).
• Tune the connection pool size to minimize the creation and destruction of database connections.
• Use JDBC directly rather than using entity beans when dealing with large amounts of data such as searching a large database.
• Combine business logic with the entity bean that holds the data needed for that logic to process.
• Tune the Message driven beans pool size to optimize the concurrent processing of messages.
• Use the setMesssageDrivenContext() or ejbCreate() method to cache bean specific resources, and release those resources from the ejbRemove() method.

http://www.precisejava.com/javaperf/j2ee/Patterns.htm
Pattern performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

• The ServiceLocator/EJBHomeFactory Pattern reduces the expensive JNDI lookup process by caching EJBHome objects.
• The SessionFacade Pattern reduces network calls by combining accesses to multiple Entity beans into one access to the facade object.
• The MessageFacade/ServiceActivator Pattern moves method calls into a separate object which can execute asynchronously.
• The ValueObject Pattern combines remote data into one serializable object, thus reducing the number of network transfers required to access multiple items of remote data.
• The ValueObjectFactory/ValueObjectAssembler Pattern combines remote data from multiple remote objects into one serializable object, thus reducing the number of network transfers required to access multiple items of remote data.
• The ValueListHandler Pattern: avoids using multiple Entity beans to access the database, using Data Access Objects which explicitly query the database; and returns the data to the client in batches (which can be terminated) rather than in one big chunk, according to the Page-by-Page Iterator pattern.
• The CompositeEntity Pattern reduces the number of actual entity beans by wrapping multiple java objects (which could otherwise be Entity beans) into one Entity bean.

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0515.html
Sun Community chat on Java BluePrints (Page last updated May 2002, Added 2002-07-24, Author Edward Ort, Publication Sun Developer, Publisher Sun). Tips:

• For very large transactions, use transaction attribute TX_REQUIRED for EJB methods to have all the method calls in a call chain use the same transaction.
• Make tightly coupled components local to each other. Put remote beans primarily as facades across subsystems.
• The page-by-page pattern is designed to handle cases where the result set is large, and the end-user is not interested in seeing all of the results. There is really no upper threshold for the size of result set in the pattern.

http://www.onjava.com/pub/a/onjava/2002/07/10/jboss.html
Clustering with JBoss (Page last updated July 2002, Added 2002-07-24, Authors Bill Burke, Sacha Labourey, Publisher OnJava). Tips:

• A hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. The load balancer can decrypt HTTPS requests and distribute load.
• HTTP session replication is expensive for a J2EE application server. If you can live with forcing a user to log in again after a server failure, then an HTTP load-balancer probably provides all of the fail-over and load-balancing functionality you need.
• If you are storing things other than EJB Home references in your JNDI tree, then you may need clustered JNDI.
• 24/7 availability needs the ability to hot-deploy and undeploy new applications and new versions, and to apply patches, without bringing down the application server for maintenance.
• Smart proxies can be used to implement load-balancing and fail-over for EJB remote clients. These proxies manage a list of available RMI connections one of which it will use to service an invocation.

http://www.theserverside.com/resources/articles/JSP-Performance/ProJsp.html
Performance chapter (chapter 20) from "Professional JSP 2nd Edition" (Page last updated August 2001, Added 2001-10-22, Author Simon Brown, Robert Burdick, Darko Cokor, Jayson Falkner, Ben Galbraith, RodJohnson, Larry Kim, Casey Kochmer, Thor Kristmundsson, Sing Li, Dan Malks, Mark Nelson, Grant Palmer, Bob Sullivan, Geoff Taylor, John Timney, Sameer Tyagi, Geert Van Damme, Steve Wilkinson, Publisher The Server Side). Tips:

• Static pages are much faster than dynamic pages, where the web server handles static pages separately.

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0305.html
Sun community chat on EJBs with Pravin Tulachan (Page last updated March 2002, Added 2002-03-25, Author Edward Ort, Publisher Sun). Tips:

• CMP (container managed persistence) is generally faster than BMP (bean managed persistence).
• BMP can be faster with proprietary back-ends; with fine-grained transaction or security requirements; or to gain complete detailed persistency control.
• Scalability is improved by passing primary keys rather than passing the entities across the network.
• EJB 2.0 CMP is far faster than EJB 1.1 CMP. EJB 1.1 CMP was not necessarily capable of scaling to high transaction volumes.
• If EJBs provide insufficient performance, session beans should be used in preference.
• Don't make fine-grained method calls across the network. Use value object and session facade design patterns instead.

http://www.hpmiddleware.com/newsletters/webservicesnews/features/
J2EE best practices. (Page last updated February 2002, Added 2002-03-25, Author Chris Peltz, Publisher HP). Tips:

• Executing a search against the database calls one of the finder() methods. finder() methods must return a collection of remote interfaces, not ValueObjects. Consequently the client would need to make a separate remote call for each remote interface received, to acquire data. The SessionFacade pattern suggests using a session bean to encapsulate the query and return a collection of ValueObjects, thus making the request a single transfer each way.
• The Value Object Assembler pattern uses a Session EJB to aggregate all required data as various types of ValueObjects. This pattern is used to satisfy one or more queries a client might need to execute in order to display multiple data types.

http://www7b.boulder.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades.html
Rules and Patterns for Session Facades (Page last updated June 2001, Added 2001-07-20, Author Kyle Brown, Publisher IBM). Tips:

• Use the Facade pattern, and specifically Value objects, to transfer all the subset of data needed from an entity bean in one transfer.

http://www.onjava.com/pub/a/onjava/2001/12/19/eejbs.html
EJBs are wonderful (Page last updated December 2001, Added 2001-12-26, Author Tyler Jewell, Publisher OnJava). Tips:

• The out-of-the-box configuration for Entity EJB engines, such as WebLogic, are designed to handle read-write transactional data with the best possible performance.
• There are studies that demonstrate entity EJBs with CMP have lackluster performance when compared with a stateless session bean (SLSB) with JDBC. [Author points out however that SLSB/JDBC combination is less robust, less configurable, and less maintainable].
• Configure separate deployments for each entity bean for different usage patterns (e.g. typical 85% read-only, 10% read-write, 5% batch update), and partition the presentation layer to use the appropriate corresponding deployment (e.g. read requests use the read-only deployment).

http://www.fawcette.com/javapro/2001_12/magazine/features/kkothapalli/
EJB performance tips (Page last updated December 2001, Added 2001-12-26, Author Krishna Kothapalli and Raghava Kothapalli, Publisher JavaPro). Tips:

• Design coarse-grained EJB remote interfaces to reduce the number of network calls required.
• Combine remote method calls into one call, and combine the data required for the calls into one transfer.
• Reduce the number of JNDI lookups: cache the home handles.
• Use session bean wrapper for returning multiple data rows from an entity bean, rather than returning one row at a time.
• Use session beans for database batch operations, entity beans typically operate only one row at a time.
• Use container-managed persistence (CMP) rather than bean-managed persistence (BMP).
• Use entity beans when only a few rows are required for the entity, and when rows need to be frequently updated.
• Use the lowest impact isolation (transaction) level consistent with maintaining data coherency. Highest impact down: TRANSACTION_SERIALIZABLE, TRANSACTION_REPEATABLE_READ, TRANSACTION_READ_COMMITED, TRANSACTION_READ_UNCOMMITED.
• Correctly simulate the production environment to tune the application, and use profiling and other monitroing tools to identify bottlenecks.
• Tune the underlying system, e.g. TCP/IP parameters, file limits, connection pool parameters, EJB pools sizes, thread counts, number of JVMs, JVM heap size, shared pool sizes, buffer sizes, indexes, SQL queries, keep/alive parameters, connection backlogs.
• Use clustering to meet higher loads or consider upgrading the hardware.

http://www.sys-con.com/java/article.cfm?id=1160
Local entity beans (Page last updated October 2001, Added 2001-10-22, Author Alex Pestrikov, Publisher Java Developers Journal). Tips:

• Local entity beans do not need to be marshalled, and do not incur any marshalling overhead for method calls either: parameters are passed by reference.
• Local entity beans are an optimization for beans which it is known will be on the same JVM with their callers.
• Facade objects (wrappers) allow local entity beans to be called remotely. This pattern incurs very little overhead for remote calls, while at the same time optimizing local calls between local beans which can use local calls.

http://www.sys-con.com/java/article.cfm?id=712
J2EE challenges (Page last updated June 2001, Added 2001-07-20, Author Chris Kampmeier, Publisher Java Developers Journal). Tips:

• Thoroughly test any framework in a production-like environment to ensure that stability and performance requirements are met.
• Each component should be thoroughly reviewed and tested for its performance and security characteristics.
• Using the underlying EJB container to manage complex aspects such as transactions, security, and remote communication comes with the price of additional processing overhead.
• To ensure good performance use experienced J2EE builders and use proven design patterns.
• Consider the impact of session size on performance.
• Applications that perform a great number of computations tend to require much more hardware per user, but can scale much better than those performing a small number of computations.

http://dev2dev.bea.com/articlesnews/discussion/thread.jsp?forum=1&thread=33
EJB Clustering (Page last updated February 2002, Added 2002-04-26, Author Tyler Jewell, Publisher BEA). Tips:

• Four locations that can provide clustering logic for an EJB are: the JNDI naming server where the home stub is bound, the container, the home stub, and the remote stub.

http://www.sys-con.com/java/article.cfm?id=673
J2EE Application servers (Page last updated April 2001, Added 2001-04-20, Authors Christopher G. Chelliah and Sudhakar Ramakrishnan, Publisher Java Developers Journal). Tips:

• A scalable server application probably needs to be balanced across multiple JVMs (possibly pseudo-JVMs, i.e. multiple logical JVMs running in the same process).
• Performance of an application server hinges on caching, load balancing, fault tolerance, and clustering.
• Application server caching should include web-page caches and data access caches. Other caches include caching servers which "guard" the application server, intercepting requests and either returning those that do not need to go to the server, or rejecting or delaying those that may overload the app server.
• Application servers should use connection pooling and database caching to minimize connection overheads and round-trips.
• Using one thread per user can become a bottleneck if there are a large number of concurrent users.

http://www.sys-con.com/java/article.cfm?id=713
Moving from JSP to EJB (Page last updated June 2001, Added 2001-06-18, Author Patrick Sean Neville, Publisher Java Developers Journal). Tips:

• Entity EJBs should contain aggregate get/set methods that return chunks of data rather than fine-grained get/set methods for individual attributes, to reduce unnecessary database, transactional, and network communication overheads.
• Avoid stateful session beans as they are resource-heavy, since one instance is maintained for each client.
• Under heavy loads, entity beans should do more than merely represent a table in a database. If you are merely retrieving and updating data values, consider using JDBC within session beans instead.
• If you have one large database host but only a small Web and middleware host, consider moving much of your logic into stored procedures and calling them via JDBC in session beans.
• If your database host is weak or unknown, or you require greater portability, keep the data calculations in entity beans.
• Consider using a single stateless session bean to provide access to other EJBs (this is a façade pattern). This optimizes multiple EJB references and calls by keeping them in-process.
• Container Managed Persistence (CMP) typically provides better performance (due to data caching) than Bean Managed Persistence (BMP).

http://www.devx.com/judgingjava/articles/maso/default.asp
Judging various aspects of Java, including performance (Page last updated May 2001, Added 2001-06-18, Author Brian Maso, Publisher DevX). Tips:

• J2EE defines component models with high scalability potential. Maximizing scalability requires sticking to stateless session beans and handling all database interactions programmatically (through pooled JDBC connections).
• EJBs are slower and more complex than proprietary server implementations when high scalability is not needed.

http://www.devx.com/premier/mgznarch/Javapro/2002/03mar02/kj0302/kj0302-1.asp
JMS vs RMI (Page last updated February 2002, Added 2002-02-22, Author Kevin Jones, Publisher DevX). Tips:

• Beans written with many getXXX() and setXXX() methods can incur an RMI round trip for every data attribute.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-extremescale.html
Clustering for J2EE and Java application servers. Looks at Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server, and WebLogic Application Server. (Page last updated February 2001, Added 2001-03-21, Author Abraham Kang, Publisher JavaWorld). Tips:

• Clustering should allow failover if a machine/process crashes. For stateful sessions, this requires state replication.
• To scale the static portions of your Website, add Web servers; to scale the dynamic portions of your site, add application servers.

http://www.javareport.com/html/from_pages/article.asp?id=799&mon=4&yr=2001
Various strategies for connecting to databases (Page last updated March 2001, Added 2001-04-20, Author Prakash Malani, Publisher Java Report). Tips:

• Obtain and release pooled conections within each method that requires the resource if the connection is very short (termed "Quick Catch-and-Release Strategy" in the article). However do not release the connection only to use it again almost immediately, instead hold the connection until it will not be immediately needed.
• The performance penalty of obtaining and releasing connections too frequently is quite small in comparison to potential scalability problems or issues raised because EntityBeans are holding on to the connections for too long.
• The "Quick Catch-and-Release Strategy" is the best default strategy to ensure good performance and scalability.

http://www.sys-con.com/weblogic/article.cfm?id=101
HTTP sessions vs. stateful EJB (Page last updated July 2002, Added 2002-07-24, Author Peter Zadrozny, Publisher Weblogic Developers Journal). Tips:

• The comparative costs of storing data in an HTTP session object are roughly the same as storing the same data in a stateful session bean.
• Failure to remove an EJB that should have been removed (from the HTTP session) carries a very high performance price: the EJB will be passivated which is a very expensive operation.

http://www.theserverside.com/resources/article.jsp?l=Tips-On-Performance-Testing-And-Optimization
Server performance testing (Page last updated 2000, Added 2001-05-21, Author Floyd Marinescu, Publisher The Server Side). Tips:

• Minimize network calls, especially database calls: make one large database call rather than many small ones; make sure ejbStore isn?t storing anything for read only operations; use Details Objects to get entity bean state rather than making many trips for each aspect of state.
• Use session beans as a façade to your entity beans to encapsulate the workflow of one entire usecase in one network call to one method on a session bean (and one transaction).

http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/
Optimizing entity beans (Page last updated May 2001, Added 2001-05-21, Author Akara Sucharitakul, Publisher Sun). Tips:

• Use container-managed persistence when you can. An efficient container can avoid database writes when no state has changed, and reduce reads by retrieving records at the same time as find() is called.
• Minimize database access in ejbStores. Use a "dirty" flag to avoid writing tee bean unless it has been changed.
• Always cache references obtained from lookups and find calls. Always define these references as instance variables and look them up in the setEntityContext (method setSessionContext for session beans).
• Avoid deadlocks. Note that the sequence of ejbStore calls is not defined, so the developer has no control over the access/locking sequence to database records.

http://www.sys-con.com/java/article.cfm?id=658
EJB best practices (Page last updated April 2001, Added 2001-05-21, Author Sandra L. Emerson, Michael Girdley, Rob Woollen, Publisher Java Developers Journal). Tips:

• To avoid resources being held unnecessarily for long periods, a transaction should never encompass user input or user think time.
• Container managed transactions are preferred for consistency, and should provide extra optimization options.
• Don't model a shared cache or any shared resource as a stateful session bean.
• Stateless session beans are easier to scale than stateful session beans. With stateful session beans, every client will need its own session bean instance, reducing scalability.
• Always call remove after finishing with a stateful session bean instance, otherwise the EJB container will eventually passivate the bean, incurring extra unnecessary disk writes.

http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html
J2EE clustering (Page last updated August 2001, Added 2001-08-20, Author Abraham Kang, Publisher JavaWorld). Tips:

• To support distributed sessions, make sure: all session referenced objects are serializable; store session state changes in a central repository.

http://forums.itworld.com/webx?14@@.ee6bdcf/598!skip=542
Avoiding memory leaks in EJBs (Page last updated April 2001, Added 2001-05-21, Author Govind Seshadri, Publisher IT World). Tips:

• Make sure that any beans which have session scope implement the HttpSessionBindingListener interface
• Explicitly release any resources that may be used within the bean by implementing the valueUnbound() callback.
• Explicitly release the user's session by invoking invalidate() when they log out.
• Try setting the session invalidation interval to a smaller value than the default 30 minutes.
• Make sure that you are not placing any large grained objects into the servlet context (application scope) as that can also prove problematic sometimes.

http://www.onjava.com/pub/a/onjava/2000/12/15/ejb_clustering.html
"EJB2 clustering with application servers" (Page last updated December 2000, Added 2001-01-19, Author Tyler Jewell, Publisher OnJava). Tips:

• [Article discusses multiple independent ways to load balance EJBs]

http://www.javareport.com/html/from_pages/article.asp?id=5769&mon=12&yr=2001
RMI arguments (Page last updated December 2001, Added 2002-02-22, Author Scott Oaks, Publisher Java Report). Tips:

• Some application servers can automatically pass parameters by reference if the communicating EJBs are in the same JVM. To ensure that this does not break the application, write EJB methods so that they don't modify the parameters passed to them.

http://www.java-zone.com/free/articles/sf0101/sf0101-1.asp
Choosing a J2EE application server, emphasizing the importance of performance issues (Page last updated February 2001, Added 2001-02-21, Author Steve Franklin, Publisher DevX). Tips:

• Application server performance is affected by: the JDK version; connection pooling availability; JDBC version and optimized driver support; caching support; transactional efficiency; EJB component pooling mechanisms; efficiency of webserver-appserver connection; efficiency of persistence mechanisms.

http://www.onjava.com/pub/a/onjava/2001/09/18/jboss.html
Implementing clustering on a J2EE web server (JBoss+Jetty) (Page last updated September 2001, Added 2001-10-22, Author Bill Burke, Publisher OnJava). Tips:

• The different EJB commit options affect database traffic and performance. Option 'A' (read-only local caching) has the smallest overhead.

http://developer.java.sun.com/developer/technicalArticles/ebeans/EJB20CMP/
EJB2.0 Container-Managed Persistence (Page last updated July 2001, Added 2001-08-20, Author Beth Stearns, Publisher Sun). Tips:

• EJB 2.0 Container-Managed Persistence provides local interfaces which can avoid the performance overheads of remote interfaces.

http://www.javareport.com/html/from_pages/article.asp?id=4702&mon=9&yr=2001
Architecting and Designing Scalable, Multitier Systems (Page last updated August 2001, Added 2001-10-22, Author Michael Minh Nguyen, Publisher Java Report). Tips:

• You can use invisible applets in a browser to validate data on the client.

http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl0619.html
Sun community discussion on "Optimizing Entity Beans" with Akara Sucharitakul (Page last updated June 2001, Added 2001-07-20, Author Edward Ort, Publisher Sun). Tips:

• Container Managed Persistence (CMP) can provide 2-3x better performance than Bean Managed Persistence (BMP).

http://www.sys-con.com/java/article.cfm?id=1081
Optimizing dynamic web pages (Page last updated July 2001, Added 2001-07-20, Author Helen Thomas, Publisher Java Developers Journal). Tips:

• Dynamic generation of web pages is more resource intensive than delivering static web pages, and can cause serious performance problems.

http://forums.itworld.com/webx?14@@.ee6b80a/534!skip=470
Stateful vs Stateless EJBs (Page last updated May 2001, Added 2001-05-21, Author Chuck Caveness, Doug Pardee, Publisher IT World). Tips:

• Stateless session beans can support multiple clients, thus increasing scalability.

http://www.theserverside.com/resources/article.jsp?l=Is-EJB-Appropriate
Deciding whether EJB is appropriate. (Page last updated September 2001, Added 2001-10-22, Author Ed Roman, Publisher The Server Side). Tips:

• An HTTP layer is not always necessary. Connecting directly to EJBs is faster and provides automatic load balancing.