InfoCenter Home >
7: Multimachine management >
7.2 Managing workloads >
7.2.1 Workload management for enterprise beans and application servers

7.2.1 Workload management for enterprise beans and application servers

Workload management for enterprise beans is enabled as follows:

  1. Create models and clones of enterprise beans, containers, and application servers.
  2. Create a workload management-enabled Java Archive (JAR) file.

Creating models and clones

Models and clones can be created for objects at any level of the containment hierarchy. A model contains the objects that are deployed into the object from which it is created. For example, individual enterprise beans can be modeled and cloned without cloning the container in which they are deployed. Clones of containers include the enterprise beans that are deployed into the modeled container. Clones of application servers include the containers and enterprise beans that are deployed onto their model, and so forth.

Creating a model and clones of an application server and enterprise beans is the first step in enabling workload management of enterprise beans. Models must be created at the application server level for workload management to function.

WebSphere Application Server uses the concept of an application server group, or cluster, to identify which application servers participate in workload management. The clones of one model of an application server constitute an application server cluster. Client processing requests are distributed among the application server instances in the cluster.

Creating workload management-enabled JAR files

A workload management-enabled JAR file enables EJB clients to access the enterprise beans through the workload management service. These JAR files can be created in two ways:

  • By using the wlmjar command-line utility. Run this utility on a JAR file into which you have deployed one or more enterprise beans.
  • By enabling workload management through the WebSphere Administrative Console. When you are deploying a JAR file (or specifying a deployed JAR file when creating an enterprise bean using the administrative console), you can enable workload management of the JAR file. This option is easier to use than the wlmjar utility.

Regardless of which method you use to enable workload management, the resulting JAR file contains stub code that allows EJB clients to access enterprise beans through the workload management service. Simply set the value of the client's CLASSPATH environment variable to the location of the workload management-enabled JAR file.

In general, deploy JAR files with workload management enabled. It does not affect their normal behavior unless models and clones are created, at which point workload management is activated.

How enterprise beans participate in workload management

The workload management service provides load balancing for the following types of enterprise beans:

  • All clones of the home object of an entity or session bean
  • All clones of an instance of a specific entity bean or stateless session bean

The reason why stateful session bean instances are treated differently than stateless session bean instances has to do with how their state is managed. As their name implies, stateless session beans do not maintain state information. All instances of a stateless session bean are considered to be identical, and each client request that it handles is treated as being made independently of any other requests.

In contrast, stateful session beans are used to store state information that must be shared among multiple and consecutive client requests that are part of a logical sequence of operations. Each instance of a particular stateful session bean is unique. It exists only in one application server and can be accessed only by directing requests to that particular application server.

Specific instances of stateful session beans cannot be shared between application servers. However, their homes can be cloned in the context of cloning the application server in which they are contained. Cloning the home object of a stateful session bean enables an application to create new instances of that bean in an application server. Multiple instances of a specific stateless session bean can exist in clones of an application server, but each instance is unique and cannot be shared.

Entity beans exist in a container only within the context of a transaction, regardless of whether the beans themselves are transactional. The workload management service uses the concept of transaction affinity to direct client requests for entity beans. After an application server is selected, client requests for that entity bean are forwarded to it for the duration of the transaction. Workload management can be used only if option C caching is enabled in the container.

Go to previous article: Managing workloads Go to next article: Workload management for servlets

 

 
Go to previous article: Managing workloads Go to next article: Workload management for servlets