Java component performance  C++ component performance

Chapter 3: Component Tuning

EJB component performance

EJB components benefit from most of the settings described in “Common component performance issues”. You can also configure common class loaders as described in “Java component performance”. You can configure the settings below to further tune EJB components.

The techniques described below are specific to EJB components. If you use EJB CMP entity beans, you can further tune the persistence settings described in Chapter 4, “EJB CMP Tuning.”

Optimizing in-server EJB calls

Most J2EE applications have EJB components that are called from other EJB components and the Web tier (servlets and JSPs). You can use the following techniques to optimize these calls:

Local interfaces

Beginning in EJB version 2.0, clients can also execute EJB components using local interfaces if the client and component execute in the same virtual machine. Using the local interface can improve performance. You can use local interfaces for intercomponent calls, and for component invocations made from servlets and JSPs hosted by the same server as the component. For more information, see “Calling local interface methods” in the EAServer Programmer’s Guide.

Lightweight container

EAServer provides a lightweight version of the standard EJB component container. The performance of some intercomponent calls in EAServer can be improved by enabling the lightweight container (LWC). The LWC coexists with the standard container. The LWC provides optimized performance for in-server EJB calls, while preserving all expected EJB semantics (such as pass by value when using remote interfaces). You can use the LWC for calls that use local or remote interfaces. The LWC can reduce CPU utilization for calls from session beans to entity beans, such that EJB-standard entity beans become as fast as lightweight persistence frameworks.

Comparing LWC to local interfaces

Both LWC and local interfaces improve performance by eliminating parameter marshalling, but the LWC provides even better performance by eliminating internal calls to enforce transactional and security requirements. You can also use LWC on EJB components that lack local interfaces, including EJB 1.1 components.

Determining if your component can use LWC

Because the LWC eliminates standard dispatcher code to enforce transaction semantics and security restrictions, you must verify that your components and the application’s use of them satisfies these restrictions before enabling LWC.

The LWC is suitable for EJB components with transaction attribute set to Required, when such components are called by other EJB components with transaction attributes “Required” or “Requires New.” EAServer verifies the following before using the lightweight container for EJB-to-EJB calls to ensure that EJB 1.1/2.0 semantics are fully preserved:

If the LWC is enabled for the called component, but the constraints are not satisfied, the call fails and EAServer logs an error.

When using the LWC, object references cannot be marshalled. For example, if component A calls B using the remote interface, and B returns a reference to component C, B will fail with exception or ClassCastException if LWC is enabled for component C. To avoid this issue, disable LWC for the target components whose object references are passed as parameters or return values, or use local interfaces to call these components.

Enabling LWC

You must enable the lightweight container in server and component properties. To enable LWC for a server, select the LWC option on the Components tab in EAServer Manager’s Server Properties dialog box. If using jagtool, set the server property to true.

To enable LWC for components, select the LWC option on the Instances tab in EAServer Manager’s Component Properties dialog box. If using jagtool, set the component property to true.

By default, the LWC supports only EJB-to-EJB intercomponent calls. You can additionally enable calls from the Web tier (servlets and JSPs) by selecting the Enable Skeletons option in the Component Properties Instances tab and on the Server Properties Components tab. This option causes EAServer to generate a skeleton that allows non-LWC invocations from the Web tier. If using jagtool, enable this option by setting the server property to true and the component property to true.

You must regenerate stubs and skeletons for your components after changing any of these settings.

You can set the server property to enable logging of additional information about LWC invocations.

Pass-by-reference semantics

EAServer supports the proprietary EJB pass-by-reference mechanism supported by some other J2EE vendors. To enable pass-by-reference for a component, set the property to true. The default is false. When set to true, EJB stubs and skeletons for the component and its home and remote interfaces use the same parameter passing mode that EAServer normally uses for EJB 2.0 local interfaces. After changing the value, you must regenerate stubs and skeletons.

This feature is not intended for new development, which should use standard EJB 2.0 local interfaces. When used, remote clients cannot call the component. The feature cannot be used with components that already have a local interface. If two or more components share the same home and remote interfaces, then all or none of those components must be configured for pass-by-reference.

Entity bean read-only methods

For entity beans that use bean-managed persistence, you can mark business methods that do not modify data. Doing so allows EAServer to skip calls to the ejbStore method after the business method returns. Performance improves through elimination of redundant database updates. Set this property using the Read Only option in the EAServer Method Properties dialog box. If using jagtool, set the method property

NoteRead-only methods in CMP entity beans When using EJB CMP entity beans, the persistence engine detects read-only method invocations. You do not need to set the Read Only method property. The ejbStore method is always called, but never performs data storage.

Entity bean database update frequency

For entity beans that use bean-managed persistence, you can configure when EAServer calls the ejbStore method by setting the property for the component, using jagtool or the Advanced tab in the EAServer Manager Component Properties dialog box.

This property specifies when ejbStore must be called. The default value of afterCreate,afterInvoke is required for EJB 2.0 compliance and is safe for all compliant entity bean implementations.

If you insert values in the ejbCreate method, and do not modify any field values in the ejbPostCreate method, you can safely remove afterCreate from the setting. Doing so improves performance by eliminating redundant updates to the database.

You can use the beforeCompletion setting rather than afterInvoke if all updates to one table come from one entity bean, and you do not mind if finder methods return stale values because updates are deferred during a transaction. While this setting yields the best performance, you may get the wrong result in architectures where more than one component can update a table, for example, if two entity beans in one transaction update the same table, or if updates from session and entity beans are mixed in one transaction.

Stateful session beans

Stateful session beans are more resource intensive than stateless session beans. The stateful implementation remains bound to the client that creates them until the client calls the remove method or EAServer removes the instance because it has timed out. You can minimize the performance impact of using stateful session beans by following these recommendations:

Copyright © 2005. Sybase Inc. All rights reserved. C++ component performance