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.”
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, introduced in the EJB 2.0 specification, improve performance by eliminating the marshalling of parameter data; in other words, parameters in component calls are passed as local data references rather than copying the object.
The EAServer Lightweight container offers further performance gain over local interfaces alone, and can be used with EJB 1.1 components and EJB 2.0 components that lack a local interface.
You can also enable Pass-by-reference semantics in EAServer to achieve the same benefits as local interfaces when using EJB 1.1 components.
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.
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.
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.
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:
The calling (source) component, servlet, or JSP uses an EJB reference or EJB local reference to make the call. No remote invocations are allowed.
The LWC is compatible with the transaction and security properties of the calling (source) and called (target) components, meaning that the target inherits the same transaction context and calling identity from the caller. The calling component must be executing a transaction, and the target cannot have the run-as identity property set.
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 java.io.NotSerializableException 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.
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 com.sybase.jaguar.server.lwc 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 com.sybase.jaguar.component.lwc 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 com.sybase.jaguar.server.lwc.enableSkeletons to true and the component property com.sybase.jaguar.component.lwc.enableSkeletons to true.
You must regenerate stubs and skeletons for your components after changing any of these settings.
You can set the server property com.sybase.jaguar.server.lwc.debug to enable logging of additional information about LWC invocations.
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 com.sybase.jaguar.component.passByReference 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.
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 com.sybase.jaguar.method.flags.
Read-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.
For entity beans that use bean-managed persistence, you can configure when EAServer calls the ejbStore method by setting the com.sybase.jaguar.component.store 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 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:
Always call the remove method Code your clients to call remove so that EAServer knows when the instance is no longer needed.
Set an instance timeout Set the component Instance Timeout property as described in he Instance Timeout setting on the Component properties: Resources tab in EAServer Manager or by setting the com.sybase.jaguar.component.timeout property with jagtool. The timeout ensures removal or passivation of component instances when the client crashes or the end user walks away from their desk.
Optionally configure passivation By default, EAServer destroys instances that time out. In single server deployments, you can optionally configure passivation so that EAServer saves the instance state data to a remote database before removing the instance from memory. Passivation allows EAServer to free memory used by idle instances, while still allowing clients to invoke the instance. If the client calls the instance again, EAServer restores the state data from the database. For more information, see “Using EJB activation and passivation” in Chapter 28, “Configuring Persistence for Stateful Session Components,” in the EAServer Programmer’s Guide.
Configure replication for clustered deployments In a clustered deployment, you must configure the mechanism that EAServer uses to replicate state data between servers in the cluster. See “Component state replication” for more information.
Configure the maximum allowed instances If clients activate too many instances at once, the server can run out of memory. To prevent this, set a limit on the number of instances that can be active. Set the Maximum Active Instances field on the Resources tab in the EAServer Manager Component Properties dialog box or by using jagtool to set the com.sybase.jaguar.component.objects property.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|