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.
Capabilities of an EJB workload enabled by the partitioning facility
Internet Inter-ORB Protocol (IIOP) driven partitions are not supported for z/OS.
The administrator can adjust this behavior after the initial bean startup to meet operational requirements, as required. For example, in the case described previously, if Partition2 and Partition4 are both very heavily loaded, and Partition 1 and Partition 3 are not, the administrator can move Partition2 to the other application server in the cluster. In this case, the programming staff can code the implementation of the PSSB1 stateless session bean to handle a partitionUnloadEvent(String) and a partitionLoadEvent(String) method. During the move partition activity that is initiated by the administrator, the Partition2 partition receives an unload event. All references to the database and other J2EE application resources are cleaned up and removed from any sort of caching implementation. Subsequently, and very quickly, the Partition2 partition is reactivated on the other application server and receives a partition load event, enabling the bean developer to reinitialize the state and prepare to process transactions.
With this technology, the client side can completely control the routing, while independently, the server-side administrator can control the final destination. Although not directly accessible, the high availability (HA) manager provides the partitioning facility (WPF) service with the underpinning to detect a failed application server. The HA manager also quickly correlates the relationship between the partitions on that server and determines which actions to take to ensure they are activated elsewhere.
The following diagram depicts a simple case of an application failover:
In the previous diagram the application server with Partition2 and Partition4 partition endpoints failed. Upon failure, the HA manager detected the failure and activates two different instances of the Partition2 and Partition4 partitions on the other application server. This is but one application server recovery scenario; other scenarios that are addressed include stopping an application server that is down for maintenance, a network partition event, and other physical or management scenarios. In this case, the Partition2 and Partition4 partitions experience an outage for a short time; however, the remainders of other partitions continue as if nothing has happened. In addition, the Partition2 and Partition4 partitions can implement a level optimization at recovery time because the implementation is advised of the partition reactivation event and can check for any problems that might need addressing during transaction recovery.
The endpoint processing can be handled in several ways depending on the computing architecture used. If you choose to have a few, reliable and manageable servers in clusters, more partition endpoints (LPAR) resources can be allocated for an application server. If you use more distributed clusters or blade centers, you can either move a partition to another standalone system that is not used or lightly loaded, or other collocated partitions that are not in use or not heavily loaded can be moved elsewhere in the cluster. This leaves the application server in the stressed partition the capacity to better handle the load. For an experienced IT staff, either option provides great deal of flexibility to meet operational requirements. The merging of existing functionality and capability with WPF framework and the underlying HA manager technology makes Extended Deployment a richer clustering solution for high-performance functionality and management to handle many typical cluster challenges.
In summary, the unique function WPF offers is a richer client request model in that the client can explicitly choose where the request is routed. In addition, not only is the endpoint uniquely addressable and targetable, but it is also a highly available endpoint. If the application server hosting the partition endpoint fails, the HA manager that is provided with Extended Deployment detects this failure and activates the partition instance on another application server in the cluster, as denoted in the following diagram. This activity is achieved without disabling any of the existing functions.
Parent topic:
EJB workload partitioning
Related concepts
WPF programming pattern in z/OSzOS