Program guide > (deprecated) Partitioning facility > The partitioning facility > J2EE partitioning capabilities
Deprecated feature: The partitioning facility (WPF) feature is deprecated. You can configure partitioning with WebSphere eXtreme Scale.
Databases like DB2/390 have built-in partitioning, and might make database partitioning in the application unnecessary.
Although you can configure a reliable cluster to run the application, if the cluster uses a single database instance the database becomes a single point of failure as well as a vertical scaling limit. The database is a single point of failure because if it becomes unavailable, no work can be done in the cluster. This is a vertical scaling problem because most databases only scale vertically; i.e. to go faster, buy a larger box.
The following diagram shows the single database server architecture. In this diagram are two WASs but only one database server. When more and more application servers are added, the database becomes a performance bottleneck.
You might require databases that scale horizontally and do not stop the entire application server cluster upon failure. Many applications with non-functional requirements allow temporary failures to impact a part of the application but a complete outage is not acceptable. Such architectures uses a partitioned database design.
An example of such a design includes three boxes running stand-alone DB2. The table schema and security system are identical for all three databases. All read-only reference data is replicated to all three databases from a master reference data DB2 instance that is made highly available in the normal way. This master reference DB2 instance is not a single point of failure during normal operation, because it is not used by the application directly.
When multiple servers are ready, the next step is to ensure the application data is partitionable. Map the data for a particular partition to a particular DB2 instance by using a simple hashing scheme or a range mechanism or by using a replicated table in the databases. The table is cached by the application server cluster and specifies the DB2 instance holding the data for a particular partition. With setup, critical data can be moved between databases without requiring application changes.
The partition to a DB2 instance table is maintained by the master and replicated to all three database nodes. An application protocol is needed to coordinate a partition from one database node to another. With coordination, an application can add a database instance to the set of databases in use for horizontal scalability. The advantage of using three independent database instances is better availability than a normal clustered database such as Oracle RAC or DB2 EEE. The databases are independent and a failure of one of the databases just means that the set of data residing there is now unavailable, but the application can continue to process transactions for the data residing in the other online database instances.
This situation is preferable to a complete failure. However, the administration is now more complex because you have three databases instead of one. The application uses directed transactions to tell the application server which database instance contains the complete data for the next transaction. This pattern provides flexible management of the database aspect of the application, especially when used with the MAPPER table that tells the application which database node has the data for a particular partition.
Applications that use CMP beans normally specify a single database to use with the CMP beans. This approach has problems when using this pattern. You can deploy the CMP beans N times, once for each database, but this is not very flexible for the following reasons:
- Requires N copies of the code with N JNDI names, and so on.
- Requires a deployment step when a database is added.
- Difficult to manage.
Extended Deployment offers a new feature, the proxy datasource, that allows the application to indicate which database to use before the transaction starts. When a cluster member receives a request for a particular application partition, it can tell the CMP runtime to ignore the data source that the beans are deployed with and to use a specific data source for the duration of the next transaction. The directed transaction pattern can be used with the application, enabling it to increase its availability, and it supports horizontal scaling of the database tier on blade-type environments. The applications can also take advantage of the MAPPER table pattern to manage data and move partitions.
The following diagram shows the new architecture. With two databases in the system, the EJB1 is deployed in both servers. In one transaction, the EJB1 in the top server accesses database 1. In another transaction, the EJB2 in the bottom server accesses database 2. The database load is spread across several database servers, instead of just one.
Parent topic:J2EE partitioning capabilities
J2EE partitioning capabilities