Program guide > (deprecated) Partitioning facility > The partitioning facility > J2EE partitioning capabilities > EJB workload partitioning
|
| |
|
|
Deprecated feature: The partitioning facility (WPF) feature is deprecated. You can configure partitioning with WebSphere eXtreme Scale.
Partitioning facility EJB workload management
The use of the partitioning facility (WPF) supports the concept of option A entity beans in the cluster. This extra performance results from the developer leveraging the programming model that is provided with WPF and in some cases using the Work Manager support that is provided in the WAS v6.0.2 product.
WPF services require one additional stateless session bean to be included in the Java™ 2 Platform Enterprise Edition (J2EE) application's Enterprise JavaBeans™ (EJB) jar. This session bean is called a partitioned stateless session bean. When the application processes the startup sequence during application server start for the EJB module, 1 to N different partitions are created. Each partition is simply a uniquely addressable end point within the cluster. Thus, in summary, a partitioned stateless session bean (PSSB) is simply a typical stateless session that utilizes WPF framework's PartitionManager to create individual partitions at bean startup and implements, in addition to the normal SessionBean interface, the PartitionHandlerLocal interface (described subsequently) to process partition related life cycle events.
WPF support services allow a PSSB to create partitions. Each partition is simply an endpoint, directly accessible by the EJB client. For this example, assume the partitioned stateless session bean, e.g. PSSB1, is included in the J2EE application and at startup creates partitions Partition1, Partition2, Partition3, and Partition4. Thus, the EJBworkload management diagram above, when the partitioned J2EE application is installed (simplified to focus on partitions), would look like the following.
The previous diagram reflects an EJB client running the same PSSB1 method ping twice. For each invocation, the first parameter differs in a string value that is provided as a method state. Later in this document, a description of how the mapping occurs is described in more detail, but for now the value of the first parameter is a key and is used by the workload manager (WLM) to route the request to a particular partition endpoint within the cluster. At cluster startup, partitions Partition1, Partition2, Partition3, and Partition4 are created when the partitioned J2EE application started and the PSSB1 home instance is instantiated. The created partitions are not servers or Java Virtual Machines (JVMs), but each does have a life cycle concept similar to a normal EJB instance when instantiated within an EJB container. One way to think of a partition is as an addressable or routable endpoint in the WLM infrastructure.
In the first case, the EJB client acquired the remote interface of the PSSB1 through the Java Naming and Directory Interface™ (JNDI) as normal, then ran the first method, ping(...), with the first parameter specifying Partition1. With Extended Deployment, programmers can advise the runtime how to process each parameter of the method invocation, and based upon the state in the method call, route each call to a specific partition.
For programming staff reading this document, the challenge for their implementation of this technology is to collocate requests with certain method state to a given application server that has exclusive access to some resource. The programmer is given extra tools during partition activation and can be notified about when and where a specific partition is loaded and unloaded. With this information, the programmer can allocate all information for a specific partition in one application. In addition, the administrator is not limited in where this processing occurs in the cluster. The partition can be moved at any time.
Parent topic:
EJB workload partitioning
Related concepts