InfoCenter Home > 7.2.1 Workload management for enterprise beans and application serversWorkload management for application servers and enterprise beans is enabled automatically when clones are created. No special configuration is needed. WebSphere Application Server uses the concept of a server group, or cluster, to identify which application servers participate in workload management. The clones of one application server group constitute an application server cluster. Processing requests from clients are distributed among the application server instances in the cluster. Migrating workload-managed enterprise beans from version 3.5 to version 4.0In version 3.5 of WebSphere Application Server, workload management for enterprise beans was enabled by using stub code that allowed EJB clients to access enterprise beans through the workload management service. The wlmjar utility was used to generate this stub code and create workload management-enabled Java Archive (JAR) files. This approach has been deprecated for version 4.0 of WebSphere Application Server. Cloned enterprise beans now automatically participate in workload management. You do not need to make any changes to enterprise beans that participated in workload management under version 3.5 of WebSphere Application Server. The workload management service simply ignores the existing stub code and workload management-enabled JAR files. However, you must remove the name of the workload management-enabled JAR file from the CLASSPATH environment variable. Replace it with the name of the original JAR file. How enterprise beans participate in workload managementThe workload management service provides load balancing for the following types of enterprise beans:
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. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|