For more detailed information and examples for Oracle Tuxedo CORBA applications, see Chapter 2, “Scaling CORBA Server Applications.”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 “Using a Stateless Object Model” on page 2‑3 and the technical article Process-Entity Design Pattern.For more information about these models, see “Server Application Concepts” in Creating CORBA Server ApplicationsProcess-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.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 manage object state 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.
•
• Parallel objects are, by definition, stateless objects so they can exist concurrently on more than one server. In release 8.0 of Oracle Tuxedo, you can use the Implementation Configuration File (ICF) to force all objects in a specific implementation to be parallel objects. The effect is to improve performance. For more information on parallel objects, see “Using Parallel Objects” on page 1‑14.The Oracle Tuxedo CORBA environment allows CORBA objects to be deployed across multiple servers to provide additional failover reliability and to split the client’s workload through load balancing. Oracle Tuxedo CORBA load balancing is enabled by default. For more information about configuring load balancing, see “Enabling System-controlled Load Balancing” on page 4‑5. For more information about distributing the application workload using Oracle Tuxedo CORBA features, see Chapter 3, “Distributing CORBA Applications.”
• 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 Oracle can balance the load by distributing processing requests across multiple server machines.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 Servers Only)” on page 1‑11.System administrators can scale an 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” on page 4‑5.
Note: Better failover occurs only when you add processes, not threads. For information about using single-threaded and multithreaded servers, see “When to Use Multithreaded CORBA Servers” on page 1‑10.The UBBCONFIG file specifies how server groups are configured and where they run. By using multiple server groups, Oracle can:To configure replicated server groups, see “Configuring Replicated Server Processes and Groups” on page 4‑5.For instructions on how to configure servers for multithreading, see “Configuring Multithreaded Servers” on page 4‑6.To configure a multithreaded CORBA server, you change settings in the application’s UBBCONFIG file. For information about defining the UBBCONFIG parameters to implement a multithreaded server, see “Configuring Multithreaded Servers” on page 4‑6.This topic introduces factory-based routing in Oracle CORBA applications. For more detailed information about using factory-based routing, see “Configuring Factory-based Routing in the UBBCONFIG File” on page 2‑11.With factory-based routing, routing is performed when a factory creates an object reference. The factory specifies field information in its call to the Oracle CORBA TP Framework to create an object reference. The TP Framework executes the routing algorithm based on the routing criteria that is defined 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.
•
• All server processes in a particular server group do not need to use the same CORBA interfaces.
• Routing criteria identifier for a CORBA interface in the INTERFACES section.
•
• Routing criteria in the ROUTING section.
Notes: When implementing factory-baed routing, remember that 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: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 “Configuring Factory-based Routing in the UBBCONFIG File” on page 2‑11.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 for CORBA Applications” in the Using the Oracle Tuxedo Domains Component.
Note: You enable the parallel objects feature by setting the concurrency policy option to user_controlled in the ICF file. For more information, see “Configuring Parallel Objects” on page 1‑17.As illustrated in Figure 1‑1, if a stateful business object is active on a server on Machine 2, all subsequent requests to that business object will be sent to Group 2 on Machine 2. If the active object on Machine 2 is busy processing another request, the request is queued. Even after the business object stops processing requests on Machine 2, all subsequent requests on that stateful business object will still be sent to Group 2. After the object is deactivated on Machine 2, subsequent requests will be sent to Group 2 on Machine 2 and can be processed by other servers in Group 2.Figure 1‑1 Using Stateful Business ObjectsAs illustrated in Figure 1‑2, if a parallel object is running on all the servers in Group 1 on Machine 1 (multiple instances of stateless, user-controlled business objects can run on multiple servers at the same time), subsequent requests to that business object will be sent to Machine 2 and distributed to the servers in Group 2 until a server becomes available in Group 1. As long as there is a server available on the local machine, requests will be distributed to the servers on Machine 1, unless the Oracle Tuxedo load-balancing feature determines that, due to loads on the servers, the request should be serviced by a server in Group 2. To make this determination, the load-balancing feature uses the LOAD parameter, which is set in the INTERFACES section of theFigure 1‑2 Using Stateless Business ObjectsUBBCONFIG file. For information on the LOAD parameter, see “Modifying the INTERFACES Section” on page 3‑10.System administrators can scale an Oracle Tuxedo application by increasing, in the UBBCONFIG file, the number of incoming client connections that an application site supports. Oracle Tuxedo provides a multicontexted, multistated gateway of listener/handlers to handle the multiplexing of all the requests issued by the client.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 File Formats, Data Descriptions, MIBs, and System Processes Reference.System administrators can scale an Oracle Tuxedo CORBA 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 client connections. To increase this number, pass the optional CLOPT -x mpx-factor parameter to the ISL command, specifying in mpx-factor the number of ISH client connections each ISH can handle (up to 4096), and therefore the degree of multiplexing, for the ISH. 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 Oracle Tuxedo applications. For more information, see the description of ISL in the File Formats, Data Descriptions, MIBs, and System Processes Reference.