EJB

Do Not Use Long Primary Keys
Designing entity beans with long primary keys results in performance degradation when the data in the underlying data store increases. Primary keys are used by the database for lookup. Database indexes make heavy use of primary keys to build hashes. Long primary keys will require more computations to hash and compare than shorter keys. Databases cache index fields to optimize performance on relational joins. Long primary keys tend to eat lot of space in the cache area, thereby opening the gates for a potentially thrashing situation.

However, how long is long? There is no bench mark for how long a primary key can be. This length depends on the volume of data anticipated in the target database table.

Some Guidelines for Effective EJB Performance Tuning
Your system needs some tuning irrespective of any good design, coding, and engineering practices adopted during development. This is particularly true of EJB-based systems as they are complex enough to warrant high testing. The following are some guidelines for performance tuning.

• What is performance? Performance is the measure of an application's ability to live up to the expectations within the environmental constraints of an enterprise.
• Performance tuning the software engineering way - know the limitations. Expecting throughput increase by a rate of 10X with only 32MB RAM and DEC PDP 11 machine is impossible.
• Measure, don't guess! Define what is expected in absolute terms. Simply iterating that performance needs to be improved will not help. Come up with an absolute figure; for example, method mytrans() should complete in three seconds. Most times it is advisable for the end users to come up with some expected performance numbers.
• Use the container. EJB containers are designed to provide a higher level of scalability through clustering, load balancing, and other means. It is important to learn the capabilities before you start tuning your performance.
• Good coding is second to none. Use design patterns wherever and whenever applicable to enable a high level of maintainability. This will help by enabling easier tuning of applications.
• Collect statistics. Before and after each step of tweaking and tuning, collect statistics. These numbers are invaluable to further planning. Compare the numbers, analyze the improvements achieved, and then plan forward if necessary.
• Take one step at a time - Rome was not built in a day. Don't do everything at step 1. Go step by step and measure at the end of each step. This will help to isolate the performance bottleneck.
• Know when to stop. Knowing when to stop is the key to tuning. Overtuning will have dire consequences. Well-documented performance criteria will help identify when to stop further turning.
• Be among good workmen - choose your tool. Use tools to guide you through the tuning process. For example, JUnitPerf will help you find the response times in various scenarios. Profilers are great tools for isolating the problem areas.
• Do not PLAN, do planning. Do not document a tuning master plan and stick to it. Performance tuning is an iterative and repeatable process. At the end of each step, measure and replan the process and define new horizons. Master plans are not practical for software turning.

Some Loose Ends
Using XML as a Silver Bullet
Filling JMS messages with XML in the name of flexibility and scalability is no panacea. Most designers/developers tend to overuse XML because it's new and hot. Overuse of XML when smart alternatives exist will severely impact application scalability.

XML is a great technology for bringing together heterogeneous environments, but it is best used judiciously. Bear in mind that XML brings in some costs too. Since XML is typeless (everything is a string), there is a type conversion and checking that need to be done. Also, parsing huge XML messages is a resource-consuming process. The overuse of XML is generally seen in JMS implementations. In this case, the MDB spends lot of time type checking and parsing the incoming XML message.

Do Not Think Too Much About Portability
One of the goals of EJB specification is to allow creation of portable components. However in reality, it is necessary to depend on extensions and enhancements that are provided by your container provider. For example, every vendor has his own proprietary deployment descriptor that allows for tuning the behavior of EJB instances. It is important to recognize that portability, though a desired feature, is not necessarily a requirement. Organizations seldom change application servers, and it is likely that you'll deploy your EJB in the same server. Thus it is advisable to take full advantage of additional features provided by your container provider.

Use Entity Beans Sparingly
As already discussed, entity beans do not naturally fit into the coarse-grained nature of distributed services. As such, they are very resource consuming and hard to change and maintain. The original goal of entity bean use is that we be able to deploy a domain model on Machine A and another domain model on Machine B, and they interoperate seamlessly through location transparency. This is seldom true because of the connecting glue called network. This resulted in developers trying to tweak the entity bean model only to make things worse.

As the lightweight container moment gains popularity, we have very good alternatives for providing transparent persistence. Hibernate, for example, comes from the open source world. It provides the transparent persistence services to POJOs. It is easily configurable and does not need a full-blown J2EE container. Sun has a new standard for transparent persistence through JDO. Although JDO is in its infancy and has not been fully embraced by J2EE vendors yet, it provides a lot of promise and is a fairly simple API.

Test, Test, and Test
Distributed components are long-term investments and they play a very vital role in a company's IT infrastructure. They are heavily used and a single failure can cause huge losses. Care must be taken to ensure that the middleware components perform very well in production. This can be ensured by rigorous testing in each phase of the development life cycle. EJB components need specialized testing as they live inside a managed environment (container). From the design to coding to integration and deployment, EJB components should be tested with all real-world use cases to ensure smoother production transition.

EJB 3.0 - The Road Ahead
The EJB architecture is probably the only J2EE component that has failed so miserably in delivering J2EE's promise of increased developer productivity thorough ease of development. EJB 3.0 makes another attempt at delivering that promise by reducing EJB's complexity for developers.