Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs.beasys.com   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
WLE Doc Home   |   Tuning & Related Topics   |   Previous   |   Next   |   Contents   |   Index

This topic introduces key concepts and tasks for scaling WebLogic Enterprise (WLE) applications. This topic includes the following sections:

• About Scaling WLE Applications

• Using Object State Management

• Replicating Server Processes and Server Groups

• Using Multithreaded Java Servers (Java only)

• Using Factory-based Routing (CORBA only)

• Multiplexing Incoming Client Connections

For more detailed information and examples for different types of WLE applications, see the following topics:

• Chapter 2, "Scaling CORBA C++ Server Applications"

• Chapter 3, "Scaling CORBA Java Server Applications"

• Chapter 4, "Scaling EJB Applications"

• For RMI applications, see Using RMI in a WebLogic Enterprise Environment.

About Scaling WLE Applications

This topic includes the following sections:

• Application Scalability Requirements

• WLE Scalability Features

• Scalability Support for WLE Applications

Application Scalability Requirements

Many applications perform adequately in an environment where between 1 to 10 server processes and 10 to 100 client applications are running. However, in an enterprise environment, applications may need to support hundreds of execution contexts (where the context can be a thread or a process), tens of thousands of client applications, and millions of objects at satisfactory performance levels.

Subjecting an application to exponentially increasing demands quickly reveals any resource shortcomings and performance bottlenecks in the application. Scalability is therefore an essential characteristic of WLE applications.

You can build highly scalable WLE applications by:

• Adding parallel processing capability to enable the WLE domain to process multiple client requests simultaneously.

• Sharing the processing load on the server applications across multiple machines.

WLE Scalability Features

WLE supports large-scale application deployments by:

• Optimizing object state management

• Load balancing objects and requests across replicated server processes and server groups

• For Java applications, using multithreaded Java servers, which are appropriate for certain types of applications and processing environments

• For CORBA applications, using factory-based routing

• Using data-dependent routing (TUXEDO only)

• Multiplexing incoming client connections

Scalability Support for WLE Applications

Table 1-1 shows how WLE scalability features support each type of WLE application.

Table 1-1 Supported Scalability Features for WLE Applications

WLE Feature	CORBA C++	CORBA Java	EJB
Object state management	Supported	Supported	Supported
Replicating server processes and server groups	Supported	Supported	Supported
Using multithreaded servers	Not Supported	Supported	Supported
Factory-based routing	Supported	Supported	Not Supported
Multiplexing incoming client connections	Supported	Supported	Supported

Note: CORBA and EJB applications require slightly different configuration parameters in the UBBCONFIG file. For more information, see "Creating a Configuration File" in the Administration Guide.

Using Object State Management

This topic includes the following sections:

• CORBA Object State Models

• EJB Object State Models

• Implementing Stateless and Stateful Objects

Object state management is a fundamental concern of large-scale client/server systems because it is critical that such systems achieve optimized throughput and response time. For more detailed information about using object state management, see the following topics:

• For CORBA C++ applications, see Using a Stateless Object Model.

• For CORBA Java applications, see Scaling with Object State Management.

• For EJB applications, see Scaling Tasks for EJB Providers.

• For all WLE applications, see the technical article Process-Entity Design Pattern.

Object State Models

This topic describes the following object state models:

• CORBA Object State Models

• EJB Object State Models

• RMI Object State Models

CORBA Object State Models

WLE CORBA supports three object state management models:

• Method-bound Objects

• Process-bound Objects

• Transaction-bound Objects

For more information about these models, see "Server Application Concepts" in Creating CORBA C++ Server Applications.

Method-bound Objects

Method-bound objects are loaded into the machine's memory only for the duration of the client invocation. When the invocation is complete, the object is deactivated and any state data for that object is flushed from memory. In this document, a method-bound object is considered to be a stateless object.

You can use method-bound objects to create a stateless server model in your application. By using a stateless server model, you move requests that are already directed to active objects to any available server, which allows concurrent execution for thousands and even millions of objects. From the client application view, all the objects are available to service requests. However, because the server application maps objects into memory only for the duration of client invocations, few of the objects managed by the server application are in memory at any given moment.

Process-bound Objects

Process-bound objects remain in memory beginning when they are first invoked until the server process in which they are running is shut down. A process-bound object can be activated upon a client invocation or explicitly before any client invocation (a preactivated object). Applications can control the deactivation of process-bound objects. In this document, a process-bound object is considered to be a stateful object.

When appropriate, process-bound objects with a large amount of state data can remain in memory to service multiple client invocations, thereby avoiding reading and writing the object's state data on each client invocation.

Transaction-bound Objects

Transaction-bound objects can also be considered stateful because, within the scope of a transaction, they can remain in memory between invocations. If the object is activated within the scope of a transaction, the object remains active until the transaction is either committed or rolled back. If the object is activated outside the scope of a transaction, its behavior is the same as that of a method-bound object (it is loaded for the duration of the client invocation).

EJB Object State Models

WLE implements Sun Microsystems, Inc. evolving Enterprise JavaBeans 1.1 Specification (Public Release 2 dated October 18, 1999). WLE fully supports the three EJB types defined in the specification:

• Stateless session beans are stateless objects and are analogous to method-bound objects in CORBA applications.

• Stateful session beans are stateful objects and are analogous to process-bound objects in CORBA applications.

• Entity beans are stateful objects and are analogous to process-bound objects in CORBA applications.

For more information about these EJB types, see "Types of Beans Supported in WLE" in The WLE Enterprise JavaBeans (EJB) Programming Environment. For more information about object state management in EJB applications, see Scaling Tasks for EJB Providers.

RMI Object State Models

In RMI applications, a conversational state exists between the client application and the object instance. RMI objects remain in memory beginning when they are first created for as long as the object exists or until the server process in which they are running is shut down. For more information about RMI applications, see Using RMI in a WebLogic Enterprise Environment.

Implementing Stateless and Stateful Objects

In general, application developers need to balance the costs of implementing stateless objects against the costs of implementing stateful objects.

About Stateless and Stateful Objects

The decision to use stateless or stateful objects depends on various factors. In the case where the cost to initialize an object with its durable state is expensive--because, for example, the object's data takes up a great deal of space, or the durable state is located on a disk very remote from the servant that activates it--it may make sense to keep the object stateful, even if the object is idle during a conversation. In the case where the cost to keep an object active is expensive in terms of machine resource usage, it may make sense to make such an object stateless.

By managing object state in a way that is efficient and appropriate for your application, you can maximize your application's ability to support large numbers of simultaneous client applications that use large numbers of objects. The way that you manage object state depends on the specific characteristics and requirements of your application:

• For CORBA applications, you do this by assigning the method activation policy to these objects, which has the effect of deactivating idle object instances so that machine resources can be allocated to other object instances.

• For EJB applications, you use stateless session beans when possible, because they can be load balanced on a per-request basis. If stateful session beans or entity beans are needed, then the application can implement

When to Use Stateless Objects

Stateless objects generally provide good performance and optimal usage of server resources, because server resources are never used when objects are idle. Using stateless objects is a good approach to implementing server applications and are particularly appropriate when:

• The client application waits for user input between invocations on the object.

• The client request contains all the data needed by the server application, and the server can process the client request using only that data.

• The object has high access rates, but low access rates from any one particular client application.

By making an object stateless, you can generally assure that server application resources are not being reserved unnecessarily while waiting for input from the client application.

An application that employs a stateless object model has the following characteristics:

• Information about and associated with an invocation is not maintained after the server application has finished executing a client request.

• An incoming client request is sent to the first available server process. After the request has been satisfied, the application state disappears and the server application is available for another client application request.

• Durable state information for the object exists outside the server process. With each invocation on this object, the durable state is read into memory.

• Successive requests on an object from a given client application may be processed by a different server process.

• The overall system performance of a machine that is running stateless objects is usually enhanced.

When to Use Stateful Objects

A stateful object, once activated, remains in memory until a specific event occurs, such as the process in which the object exists is shut down, or the transaction in which the object is activated is completed.

Using stateful objects is recommended when:

• An object is used frequently by a large number of client applications, such as long-lived, well-known objects. When the server application keeps these objects active, the client application typically experiences minimal response time in accessing them. These active objects are shared by many client applications, and therefore relatively few objects of this type exist in memory.

  Note: You should carefully consider how objects will potentially be involved in a transaction. An object can be bound to a particular process temporarily (transaction-bound) or permanently (process-bound). An object that is involved in a transaction cannot be invoked by another client application or object (WLE will likely return an error indicating that the object is busy). Stateful objects that are intended to be used by a large number of client applications can create bottlenecks if they are involved in transactions frequently or for long durations.

• A client application must invoke successive operations on an object to complete a transaction, and the client application is not idle while it waits for user input between invocations. If the object were deactivated between invocations, there would be a degradation of response time because state would be written and read between each invocation. In EJB applications, stateful objects can be passivated at any time. Such behavior may not be appropriate for transactions. You should consider holding server resources in exchange for better response time.

Stateful objects have the following behavior:

• State information is maintained between server invocations, and the object typically remains dedicated to a given client application for a specified duration. Even though data is sent and received between the client and server applications, the server process maintains additional context or application state information in memory.

• When one or more stateful objects use a lot of machine resources, server performance for tasks and processes not associated with the stateful object may be lower than with a stateless server model.

  For example, if an object has a lock on a database and is caching large amounts of data in memory, that database and the memory used by that stateful object are unavailable to other objects, potentially for the entire duration of a transaction.

Replicating Server Processes and Server Groups

This topic includes the following sections:

• About Replicating Server Processes and Server Groups

• Configuration Options

• Replicating Server Processes

• Replicating Server Groups

For more detailed information about replicating server processes and server groups, see the following topics:

• Configuring Replicated Server Processes and Groups

• For CORBA C++ applications, see Scaling by Replicating Server Processes and Server Groups.

• For CORBA Java applications, see Scaling by Replicating Server Processes and Server Groups.

• For EJB applications, see Scaling Tasks for System Administrators.

About Replicating Server Processes and Server Groups

The WLE environment allows CORBA objects and EJBs to be deployed across multiple servers to provide additional failover reliability and to split the client's workload through load balancing. WLE load balancing is enabled by default. For more information about load balancing, see Enabling Load Balancing. For more information about distributing the application workload using TUXEDO features, see Distributing Applications.

The WLE architecture provides the following server organization:

• Groups. Individual servers can be combined to form a group. A group of servers runs on a single machine. Typically, the servers in a group access common resources (such as a database).

• Domains. Machines can be combined to form a domain. A domain is administered centrally. Multiple domains are administered separately. Domains can also be interconnected and requests can be transparently routed from one domain to another. However, each domain is independently administered.

This architecture allows new servers, groups, or machines to be dynamically added or removed, to adapt the application to high- or low-demand periods, or to accommodate internal changes required to the application. The WLE run time provides load balancing and failover by routing requests across available servers.

System Administrators can scale a WLE application by:

• Replicating Server Processes. Increase the number of server processes to support more active objects within a group and load balancing among servers.

• Replicating Server Groups. Increase the number of server groups so that WLE can balance the load by distributing processing requests across multiple server machines.

Configuration Options

You can configure server applications as:

• A single machine with one or more server processes implementing one or more interfaces. For Java, the servers can be single-threaded or multithreaded.

• Multiple machines with multiple server processes and multiple interfaces.

You can add more parallel processing capability to client/server applications by replicating server processes or add more threads. You can add more server groups to split processing across resource managers. For CORBA applications, you can implement factory-based routing, as described in Using Factory-based Routing (CORBA only).

Replicating Server Processes

System Administrators can scale an EJB application by replicating the servers to support more concurrent active objects, or process more concurrent requests, on the server node. To configure replicated server processes, see Configuring Replicated Server Processes and Groups.

Benefits

The benefits of using replicated server processes include:

• Load balancing incoming requests.

• Processing client requests on any server within a group. As requests arrive in the WLE domain for the server group, WLE routes the request to the least busy server process within that group.

• Improving the server application's performance by using multiple server processes. Instead of having one server process handling one client request at one time, multiple server processes are available to handle multiple client requests simultaneously.

• Providing failover protection in the event that one of the server processes stops.

Guidelines

To achieve the maximum benefit of using replicated server processes, make sure that the CORBA objects or entity beans instantiated by your server application have unique object IDs. This allows a client invocation on an object to cause the object to be instantiated on demand, within the bounds of the number of server processes that are available, and not queued up for an already active object.

You should also consider the trade-off between providing better application recovery by using multiple processes versus more efficient performance using threads (for some types of application patterns and processing environments).

Better failover occurs only when you add processes, not threads. For information about using single-threaded and multithreaded Java servers, see When to Use Multithreaded Java Servers.

Replicating Server Groups

Server groups are unique to WLE and are key to WLE's scalability features. A group contains one or more servers on a single node. System administrators can scale a WLE application by replicating server groups and configuring load balancing within a domain.

Replicating a server group involves defining another server group with the same type of servers and resource managers to provide parallel access to a shared resource (such as a database). CORBA applications, for example, can use factory-based routing to split processing across the database partitions.

The UBBCONFIG file specifies how server groups are configured and where they run. By using multiple server groups, WLE can:

• Spread the processing load for a given application or set of applications across additional machines.

• Use factory-based routing (for CORBA applications) to send one set of requests on a given interface to one group, and another set of requests on the same interface to another group.

To configure replicated server groups, see Configuring Replicated Server Processes and Groups.

Using Multithreaded Java Servers (Java only)

This topic includes the following sections:

• About Multithreaded Java Servers

• When to Use Multithreaded Java Servers

• Coding Recommendations

• Configuring a Multithreaded Java Server

For instructions on how to configure Java servers for multithreading, see Configuring Multithreaded Java Servers.

Note: C++ servers are single-threaded only.

About Multithreaded Java Servers

System administrators can scale a WLE application by enabling multithreading in Java servers, and by tuning configuration parameters (the maximum number of server worker threads that can be created) in the application's UBBCONFIG file.

WLE Java supports the ability to configure multithreaded WLE Java applications. A multithreaded WLE Java server can service multiple object requests simultaneously, while a single-threaded WLE Java server runs only one request at a time. Running a WLE Java server in multithreaded mode or in single-threaded mode is transparent to the application programmer. Programs written to WLE Java run without modification in both modes.

Server worker threads are started and managed by the WLE Java software rather than an application program. Internally, WLE Java manages a pool of available server worker threads. If a Java server is configured to be multithreaded, then when a client request is received, an available server worker thread from the thread pool is scheduled to execute the request. Each active object has an associated thread, and while the object is active, the thread is busy. When the request is complete, the worker thread is returned to the pool of available threads.

In this release, you should not establish multiple threads programmatically in your server implementation code. Only worker threads that are created by the run-time WLE Java server software can access the WLE Java infrastructure, which means that your Java server application should not create a Java thread from a worker thread and then attempt to begin a new transaction in the thread. You can, however, start threads in your server application to perform other, non-WLE operations.

When to Use Multithreaded Java Servers

Deploying multithreaded Java servers is appropriate for many, but not all, WLE Java applications. The potential for a performance gain from a multithreaded Java server depends on whether:

• the application is running on a single- or a multiprocessor machine

• the application is CPU-intensive or I/O-intensive

If the application is running on a single-processor machine and the application is CPU-intensive only (for example, without any I/O), in most cases the multithreaded Java server will not increase performance. In fact, due to the overhead of switching between threads, using a multithreaded Java server in this configuration might result in a performance loss rather than a gain.

In general, however, WLE Java applications almost always perform better when running on multithreaded Java servers. Multiple multithreaded servers should be configured to distribute the load across servers. If only a single server is configured, that server's queue could fill up quickly.

Coding Recommendations

The code used in a multithreaded WLE server application appears the same as a single-threaded application. However, if you plan to configure your Java server applications to be multithreaded, or you want to have the option do so in the future, consider the following recommendations:

• Do not start threads in your Java server code, and keep threading transparent in your source files.

• Write thread-safe code in your server and client code. Use standard Java synchronization techniques to make sure that static variables are properly synchronized. For more information about Java synchronization techniques, see Sun Microsystem's Java Language Specification.

• Configure the Java server as single-threaded if your application uses JNI code to access ATMI.

• Configure the Java server as multithreaded if an XA-enabled version of Java server is built using buildXAJS . The server must be configured to support multithreaded mode.

• Include one of the following identifiers in each message if your client or server application sends messages to the user log (ULOG):

  • object ID

  • thread name

  • transaction ID (if the object is transactional)

Configuring a Multithreaded Java Server

To configure a multithreaded Java server, you change settings in the application's UBBCONFIG file. For information about defining the UBBCONFIG parameters to implement a multithreaded Java server, see Configuring Multithreaded Java Servers.

Using Factory-based Routing (CORBA only)

This topic includes the following sections:

• About Factory-based Routing

• How Factory-based Routing Works

• Configuring Factory-based Routing in the UBBCONFIG File

This topic introduces factory-based routing in WLE CORBA applications. For more detailed information about using factory-based routing, see the following topics:

• For CORBA C++ applications, see Configuring Factory-based Routing in the UBBCONFIG File.

• For CORBA Java applications, see Configuring Factory-based Routing in the UBBCONFIG File.

About Factory-based Routing

Factory-based routing is a feature that lets you send a client request to a specific server group. Using factory-based routing, you can distribute that processing load for a given application across multiple machines, because you can determine the group and machine in which a given object is instantiated.

Routing is performed when a factory creates an object reference. The factory specifies field information in its call to the WLE TP Framework to create an object reference. The TP Framework executes the routing algorithm based on the routing criteria that you define in the ROUTING section of an application's UBBCONFIG file. The resulting object reference has, as its target, an appropriate server group for the handling of method invocations on the object reference. Any server that implements the interface in that server group is eligible to activate the servant for the object reference.

The activation of CORBA objects can be distributed by server group based on defined criteria, in cooperation with a system designer. Different implementations of CORBA interfaces can be supplied in different groups. This feature enables you to replicate the same CORBA interface across multiple server groups, based on defined, group-specific differences.

The system designer of the application must communicate the factory-based routing criteria to the system administrator. In the BEA TUXEDO system, an FML field used for a service invocation can be used for routing. You can independently discover this information because there is no service request message data or associated buffer information available for routing. Routing is performed at the factory level and not on a method invocation on the target CORBA object.

The primary benefit of factory-based routing is that it provides a simple means to scale up an application, and invocations on a given interface in particular, across a growing deployment environment. Distributing the deployment of an application across additional machines is strictly an administrative function that does not require you to recode or rebuild the application.

Characteristics of Factory-based Routing

Factory-based routing has the following characteristics:

• An implementation of a particular CORBA interface can exist in more than one server process, as shown in Configuring Factory-based Routing in the UBBCONFIG File.

• Multiple CORBA interfaces can reside in a single server group.

• All server processes in a particular server group do not need to use the same CORBA interfaces.

• The factory object implementation can indirectly control the location of the created CORBA object by supplying application-specific routing information.

• Routing uses the Bulletin Board criteria and occurs in a server call.

• All instances that offer a given interface within a group must support the same version of the implementation.

How Factory-based Routing Works

To implement factory-based routing, you change the way your factories create object references.

• You coordinate with the system designer to determine the fields and values to be used as the basis for routing.

• For each interface, you need to configure factory-based routing. The interface definition for the factory must specify the parameter that represents the routing criteria used to determine the group ID.

• In the UBBCONFIG file, you need to define the following information:

  • Routing criteria identifier for a CORBA interface in the INTERFACES section

  • As many server groups as are required for distributing the system in the GROUPS section

  • Routing criteria in the ROUTING section

  • Groups, machines, and databases as required.

• An object with a given interface and OID can be simultaneously active in two different groups if those two groups both contain the same object implementation. This can be avoided if your factories generate unique OIDs. To guarantee that only one object instance of a given interface name and OID is available at any one time in your domain, you must either:

  • Use factory-based routing to ensure that objects with a particular OID are always routed to the same group, or

  • Configure your domain so that a given object implementation is in only one group.

    If multiple clients have an object reference that contains a given interface name and OID, the reference will always be routed to the same object instance.

Thereafter, the object reference will contain additional information that is used to provide an indication of where the target server exists. Factory-based routing is performed once per CORBA object, when the object reference is created.

Configuring Factory-based Routing in the UBBCONFIG File

Routing criteria specify the data values used to route requests to a particular server group. To configure factory-based routing, you define routing criteria in the ROUTING section of the UBBCONFIG file (for each interface for which requests are routed). For more detailed information about configuring factory-based routing, see the following topics:

• For CORBA C++, see Configuring Factory-based Routing in the UBBCONFIG File.

• For CORBA Java, see Configuring Factory-based Routing in the UBBCONFIG File.

To configure factory-based routing across multiple domains, you must also configure the factory_finder.ini file to identify factory objects that are used in the current (local) domain but that are resident in a different (remote) domain. For more information, see "Configuring Multiple Domains (WLE System)" in the Administration Guide.

Multiplexing Incoming Client Connections

This topic includes the following sections:

• IIOP Server Listener and Handler

• Increasing the Number of ISH Processes

System Administrators can scale a WLE application by increasing, in the UBBCONFIG file, the number of incoming client connections that an application site supports. WLE provides a multicontexted, multistated gateway of listener/handlers to handle the multiplexing of all the requests issued by the client.

IIOP Server Listener and Handler

The IIOP Server Listener (ISL) enables access to WLE objects by remote WLE clients that use IIOP. The ISL is a process that listens for remote clients requesting IIOP connections. The IIOP Server Handler (ISH) is a multiplexor process that acts as a surrogate on behalf of the remote client. Both the ISL and ISH run on the application site. An application site can have one or more ISL processes and multiple associated ISH processes. Each ISH is associated with a single ISL.

The client connects to the ISL process using a known network address. The ISL balances the load among ISH processes by selecting the best available ISH and passing the connection directly to it. The ISL/ISH manages the context on behalf of the application client. For more information about ISL and ISH, see the description of ISL in the WebLogic Enterprise Reference.

Increasing the Number of ISH Processes

System administrators can scale a WLE application by increasing the number of ISH processes on an application site, thereby enabling the ISL to load balance among more ISH processes. By default, an ISH can handle up to 10 processes. To increase this number, pass the optional CLOPT -x mpx-factor parameter to the ISL command, specifying in mpx-factor the number of ISH processes (up to 4096), and therefore the degree of multiplexing, for that ISL. Increasing the number of ISH processes may affect application performance as the application site services more concurrent processes.

System administrators can tune other ISH options as well to scale WLE applications. For more information, see the description of ISL in the WebLogic Enterprise Reference.