Chapter 3 Understanding Transactions and Component Lifecycles

Component lifecycles

The Jaguar component lifecycle is designed to:

• Maximize sharing and reuse of server resources
• Minimize the possibility that a client application can monopolize server resources

To achieve these goals, Jaguar 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 Jaguar components in any component model follow the state diagram illustrated in this figure:

The state transitions are as follows:

• New instance The Jaguar runtime allocates a new instance of the component. The instance remains idle in the instance pool waiting for the first method invocation.
• Activation Activation prepares a component instance for use by a client. Once an instance is activated, it is bound to one client and can service no other client until it has been deactivated. If a component is transactional, activation also indicates the beginning of the instance's participation in a transaction.
• In method In response to a method invocation request from the client, the Jaguar runtime calls the corresponding method in the component. The next state depends on which of the transaction state primitives the method calls before returning. (For Java components, the state transition also depends on whether the method returns with an uncaught exception.) See "Using transaction state primitives" for more information.
• Deactivation Deactivation indicates that the component is no longer bound to the client. Methods can call either the completeWork or rollbackWork transaction state primitives to cause explicit deactivation of the instance. As discussed in "Using transaction state primitives", these primitives also affect the transaction's outcome. Deactivation can also occur automatically, under any of the following circumstances:
  • If the instance is participating in a transaction, the instance is deactivated when the transaction commits, rolls back, or times out.
  • If you have configured the component's Instance Timeout property to a finite setting, an instance is deactivated if the time between consecutive method calls exceeds the timeout value. "Resources tab component properties" describes how to configure this property.
• Destruction Destruction occurs if the component instance cannot be recycled. "Supporting instance pooling in your component" describes how to ensure instance reuse. If the component cannot be reused, deactivation is followed by destruction of the instance.

The Jaguar 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. There are two ways to support early deactivation:

• Code your component to call one of the completeWork or rollbackWork transaction state primitives to cause explicit deactivation of the instance. This technique is useful when your design requires deactivation to occur after some, but not all, method invocations. If the component is transactional, the completeWork and rollbackWork primitives also affect the outcome of the transaction in which the component is participating. See "Using transaction state primitives" for more information.
• Enable the Auto demarcation/deactivation option on the Transactions tab of Component Properties window (see "Transactions tab component properties" for more information). When this option is enabled, the component is automatically deactivated after every method invocation.

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:

• Java components can implement the interface jaguar.beans.enterprise.ServerBean. See Chapter 1, "Java Classes and Interfaces", of the Jaguar CTS API Reference for details.
• ActiveX components can implement the IObjectControl interface and the GetObjectContext method. See Chapter 2, "ActiveX C++ Interface Reference", of the Jaguar CTS API Reference for details.

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 Jaguar 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 Jaguar Manager, the Java canReuse or ActiveX canBePooled method is not called, even if the component implements the ServerBean Java interface or IObjectControl ActiveX interface.

Stateful vs. 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 "Resources tab component properties" for more information.

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

• You have configured or implemented the component to be deactivated after every method invocation. In Jaguar Manager, you can enable the Automatic deactivation / demarcation property for the component (located on the Transactions tab in the Component Properties window). Alternatively, you can implement the component so that it calls either completeWork or rollbackWork in every method.
• You have enabled the Pooling option in the Component Properties window (this option is located on the Instances tab).

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:

• Accumulate data in a remote database Use connection caching and database commands to accumulate data in a remote database. This is the preferred technique. If you deploy your component to a cluster, it may run on multiple servers and the database provides a central location available from all servers.
• Accumulate data in the client Create a data structure that is passed to each method invocation and contains all accumulated data. This technique is only practical if the amount of data is small. Sending large amounts of data over the network will degrade performance.
• Accumulate data in a file If the accumulated data is small and represented by simple data structures, you can store the data in a local file.
• Use the Jaguar shared objects feature Jaguar provides a shared objects interface that allows components to store references to shared data. For more information, see the following sections:
  • "Share data between instances" describes the shared objects interface for Java components.
  • Chapter 19, "Creating ActiveX Components", describes the shared objects interface for ActiveX components.
  • "Share data between C or C++ components" describes the shared objects interface for C components.

Copyright © 2000 Sybase, Inc. All rights reserved.