3.6 Parallel Objects

Support for parallel objects was added to Oracle Tuxedo CORBA in release 8.0 as a performance enhancement. The parallel objects feature enables you to designate all business objects in a particular application as stateless objects. The effect is that, unlike stateful business objects, which can only run on one server in a single domain, stateless business objects can run on all servers in a single domain. Thus, the benefits of parallel objects are as follows:

• Parallel objects can run on multiple servers in the same domain at the same time. Thus, utilization of all servers to service concurrent multiple requests improves performance.
• When the Oracle Tuxedo system services requests to parallel business objects, it always looks for an available server to the local machine first. If all servers on the local machine are busy processing the requested business object, the Oracle Tuxedo system looks for an available server on other machines in the local domain. Thus, if there are multiple servers on the local machine, network traffic is reduced and performance is improved.

For more information on parallel objects, see Using Parallel Objects.

To implement parallel objects, the concurrency policy option has been added to the ICF file. To select parallel objects for a particular application, you set the concurrency policy option to user-controlled. When you select user-controlled concurrency, the business object is not registered with the Active Object Map (AOM) and, therefore, are stateless and can be active on more than one server at a time. Thus, these objects are referred to as parallel objects.

If user-controlled concurrency is selected, the servant implementation must comply with one of the following statements:

• The servant implementation must have no requirements for concurrent access to a shared resource
• Or the servant implementation must utilize some other tool (for example, a database and locking) to ensure the correct behavior during concurrent access to resources.

In release 8.0 of the Oracle Tuxedo software, the Implementation Configuration File (ICF) was modified to support user-controlled concurrency. In following listing, the changes to add this support are highlighted in bold type. For a description of the ICF syntax, see ICF Syntax .

[#pragma activation_policy method | transaction | process]
[#pragma transaction_policy never | ignore | optional | always]
[#pragma concurrency_policy user_controlled | system_controlled]
[Module module - name {
   ]
   implementation[implementation - name] {
      implements(module - name::interface - name);
      [activation_policy(method | transaction | process);]
      [transaction_policy(never | ignore | optional | always);]
      [concurrency_policy(user_controlled | system_controlled);]
   };
   [
   };
]

User-controlled concurrency can be used with factory-based routing, all activation policies, and all transaction policies. The interaction with these features is as follows:

• Factory-based routing

  If the user specifies factory-based routing when creating the object, then the object will route to a server in that group. The object key contains the group selected during factory-based routing, but the client routing code will recognize that the interface has user-controlled concurrency and specify the desired group. This is accomplished using normal Oracle Tuxedo routing.

• Activation policy

  The TP Framework handles active user-controlled concurrency objects in the same manner as system-controlled concurrency objects. The TP Framework stores information about objects in the local AOM, and calls the activate_object and deactivate_object methods at the appropriate times. However, the object will not have an entry in the AOM and the TP Framework will not call any AOM routines. For example, on shutdown, since an active object will not have an AOM handle, calls to remove the entry from the AOM will not be invoked.

• Transaction policy

  The TP Framework handles active user-controlled concurrency objects in the same manner as system-controlled concurrency objects. The TP Framework is called back for transaction events and the TP Framework stores information about transactional user-controlled objects in the local AOM. The main differences when using parallel objects in transactions as opposed to stateful objects are that the AOM is not used for GTRID information and the AOM routines are not called to update or retrieve transactional information.

Note:

There is one restriction with user-controlled concurrency. TP::create_active_object_reference throws a TobjS::IllegalOperation exception if it is passed an interface with user-controlled concurrency set. Since the AOM is not used when user-controlled concurrency is set, there is no way for the TP Framework to connect an active object to this server.