2.6.2 Instantiating the Registrar and Teller Objects

In the University server applications that are less sophisticated than the Production sample application, the run-time behavior of the Registrar and Teller objects was simpler:

• Each object was process-bound, meaning that each was activated the first time it was invoked, and it stayed in memory until the server process in which it ran was shut down.
• Since there was only one server group running in the Oracle Tuxedo domain, and only one University and Billing server process in the group, all client requests were directed to the same objects. As multiple client requests arrived in the Oracle Tuxedo domain, these objects each processed one client request at one time.
• Because there was only one instance of each object in the server processes in which they ran, neither object needed a unique OID. The OID for each object specified only the Interface Repository ID.

However, because the University and Billing server processes are now replicated, Oracle Tuxedo CORBA must be able to differentiate among multiple instances of the Registrar and Teller objects. For example, if there are two University server processes running in a group, Oracle Tuxedo CORBA must have a means to distinguish between the Registrar object running in the first University server process and the Registrar object running in the second University server process. To distinguish multiple instances of these objects, each object instance must be unique.

To make each Registrar and Teller object unique, the factories for those objects must change the way in which they make object references to them. For example, when the RegistrarFactory object in the Basic sample application created an object reference to the Registrar object, the TP::create_object_reference() operation specified an OID that consisted only of the string registrar. However, in the Production sample application, the same TP::create_object_reference() operation uses a generated unique OID instead.

As a result of giving each Registrar and Teller object a unique OID, multiple instances of these objects may be running simultaneously in the Oracle Tuxedo domain. This characteristic is typical of the stateless object model, and is an example of how the Oracle Tuxedo domain can be highly scalable while it offers high performance.

Finally, because unique Registrar and Teller objects need to be brought into memory for each client request on them, it is critical that these objects be deactivated when the invocations on them are completed so that any object state associated with them does not remain idle in memory. The Production server application addresses this issue by assigning the method activation policy to these two objects in the Implementation Configuration File (ICF).