|
|
This section describes the contents and organization of this guide—Using WebLogic ServerŪ Clusters.
This document is written for application developers and administrators who are developing or deploying Web-based applications on one or more clusters. It also contains information that is useful for business analysts and system architects who are evaluating WebLogic Server or considering the use of WebLogic Server clusters for a particular application.
The topics in this document are primarily relevant to planning, implementing, and supporting a production environment that includes WebLogic Server clusters. Key guidelines for software engineers who design or develop applications that will run on a WebLogic Server cluster are also addressed.
It is assumed that the reader is familiar with J2EE, HTTP, HTML coding, and Java programming (servlets, JSP, or EJB development).
The following sections describe new features and changes for Clusters in WebLogic Server 9.2:
For a comprehensive listing of the new WebLogic features introduced in release 9.2, see " What's New in WebLogic Server 9.2" in Release Notes.
| Note: | WebLogic Server changed substantially in version 9.0, and these changes apply to later releases as well. For a detailed description of features and functionality introduced in WebLogic Server 9.0, see " What's New in WebLogic Server 9.0. For information about new and changed functionality in subsequent releases, see the What's New in WebLogic Server document for each release. |
| Note: | Server Migration is not supported on all platforms. See Server Migration in WebLogic Platform 9.2 Supported Configurations. |
This release provides server migration support for HP-UX platform configurations.
Automatic singleton service migration allows the automatic health monitoring and migration of singleton services. A singleton service is a user-defined service operating within a cluster that is available on only one server at any given time.
When a migratable service fails or become unavailable for any reason (for example, because of a bug in the service code, server failure, or network failure), it is deactivated at its current location and activated on a new server.
For more information, see Automatic Singleton Service Migration.
A database is no longer required to store leasing information that is used during server migration. For more information, see Leasing.
The Job Scheduler functionality is an implementation of the commonj.timer API that can be used within a clustered environment. Job Schedulers allow cluster-wide timers to be aware of the other JVMs containing each server within the cluster and is therefor able to perform load balancing and failover. For information on using the Job Scheduler, see
Using the Timer API Within a Cluster in The Timer and Work Manager API (CommonJ).
|