Chapter 2: Understanding Transactions and Component Lifecycles  EAServer’s transaction processing model

Chapter 2: Understanding Transactions and Component Lifecycles

Component lifecycles

The EAServer component lifecycle is designed to:

To achieve these goals, EAServer supports the concepts of component instance pooling and early deactivation.

Instance pooling allows a single component instance to service multiple clients. The component lifecycle contains activation and deactivation steps: Activation binds an instance to an individual client; deactivation indicates that the instance is unbound. Instance pooling eliminates resource drain from repeated allocation of component instances.

Early deactivation allows a component’s methods to specify when deactivation occurs. Early deactivation prevents a client application from tying up the resources that are associated with a component instance and allows the instance to serve more clients in a given time frame. To achieve early deactivation, you can code or configure your component as described in “Supporting early deactivation in your component”.

A component that is deactivated after each method call and supports instance pooling is said to be a stateless component because the component’s state is reset across the boundary of a transaction and activation. Early deactivation and instance pooling promotes greater scalability by enabling an increasing number of clients to use a static number of instances. An application design based on stateless components offers the greatest scalability.

States in the component lifecycle

Generic component lifecycle EAServer components in any component model follow the state diagram illustrated in this figure:

Figure 2-1: States in the EAServer component lifecycle

The state transitions are as follows:

The EAServer component lifecycle allows component instances to be recycled; idle component instances can be cached when idle and bound to the service of individual clients only as needed. If your component has been coded to support early deactivation, a client holding a reference to the component’s stub or proxy object may be serviced by several different instances of the component. After each deactivation, the next method invocation causes an instance to be activated and bound to the client. Overall server scalability is increased because a new instance does not have to be instantiated each time a client invokes a method.

Supporting early deactivation in your component

Early deactivation prevents a client application from tying up the resources (such as connections) that are associated with a component instance.

EJB stateless session beans and entity beans support early deactivation by design. If you have coded the component according to the EJB specification, no additional code or configuration is required to run in EAServer.

For components of other types, there are several ways to support early deactivation:

Supporting instance pooling in your component

Instance pooling eliminates resource drain caused by repeated allocation of new component instances.

For Java and ActiveX components, you can implement a lifecycle-control interface to control whether the component instances are pooled. These interfaces also provide activate and deactivate methods that are called to indicate state transitions in a component instance’s lifetime. For more information on these interfaces, see the following sections:

For PowerBuilder components, you can enable the Pooling option on the PowerBuilder wizard that you use to create your component. You can then write event scripts that respond to changes in an instance’s lifecycle. See the Application Techniques manual in the PowerBuilder documentation for more information.

For C and C++ components, you can enable instance pooling using EAServer Manager. Display the Instances tab in the Component Properties window, then select the Pooling option. This option also allows you to configure pooling for Java and ActiveX components that do not implement the ServerBean or IObjectControl interfaces, respectively.

To support instance pooling, code that responds to activation events must restore the component to its initial state (that is, as if it were newly created). Both the Java and ActiveX interfaces have methods that allow an instance to selectively refuse pooling: canReuse in Java, canBePooled in ActiveX. For PowerBuilder components, you can script the canBePooled event to selectively refuse pooling.

When the component Pooling option is set in EAServer Manager, the Java canReuse or ActiveX canBePooled method is not called, even if the component implements the ServerBean Java interface or IObjectControl ActiveX interface.

You can configure the component pooling properties to control how many instances are pooled, and to assign different components to a shared pool. For information on tuning these settings, see “Instance pooling” in Chapter 3, “Component Tuning,” in the EAServer Performance and Tuning Guide.

Stateful versus stateless components

A component that can remain active between consecutive method invocations is called a stateful component. A component that is deactivated after each method call and that supports instance pooling is said to be a stateless component. Typically, an application built with stateless components offers the greatest scalability.

Stateful components A stateful component remains active across method calls.

Since deactivation happens at the mercy of client applications, you may wish to configure the Instance Timeout property for stateful components so that a client cannot monopolize a component instance indefinitely. See “Component properties: Resources” for more information.

Stateless components In order for a component to be stateless, both of the following must be true:

Stateless components cannot use instance-specific data to accumulate data between method invocations.

Some situations require that you accumulate data across method invocations. For example, a PurchaseOrder component might have an addItem() method that is called repeatedly to specify the contents of an order. In lieu of instance-specific data, you can use one of these alternatives to accumulate data:





Copyright © 2005. Sybase Inc. All rights reserved. EAServer’s transaction processing model