Objectivity/DB Administration : Administration Tasks : Rehosting an Application
15 
Rehosting an Application
Within a heterogeneous Objectivity/DB system, you may decide to move an application to a new client host. This chapter provides information you should consider when rehosting an application, including:
General information about changing client hosts.
Guidelines for deciding whether to change the owning architecture of storage pages.
Steps for changing storage-page ownership.
Understanding the Implications of Changing Client Hosts
Within a heterogeneous Objectivity/DB system, you may decide to move an application to a new client host, from which the application will continue to access the existing federated database. If the old and new client hosts are of the same architecture, you simply copy the relevant executable and libraries; you may also need to adjust the pathname the application uses to find the boot file.
If, however, the old and new client hosts are of different architectures, you must rebuild the application for the new architecture. See Host Architectures.
Furthermore, you should decide whether to convert the existing federated database so its storage pages are owned by the new client-host architecture. See Deciding Whether to Change Storage-Page Ownership and Changing the Ownership of Storage Pages.
Note:The owning architecture of storage pages is completely independent of the architecture of data-server hosts, so you do not need to convert any storage pages after installing a federated database (or any of its files) on a data-server host of a different architecture.
Disk Format of Storage Pages
Every storage page has a disk format that is used for all persistent objects stored on that page. The disk format of a storage page establishes such things as the conventions governing the binary representation of the persistent objects on the page. Objectivity/DB defines a unique disk format for every architecture it supports. The architecture that defines the disk format of a particular storage page is said to own the page. An application sets the owning architecture of every storage page it creates; by default, the owning architecture is the client-host architecture of the application. (The owning architecture of storage pages is not affected by the architecture of a data-server host.)
When an application reads a persistent object, the object’s storage page is brought into memory (the Objectivity/DB cache), and the object is converted from its disk format to a format suitable for in-memory access. When the owning architecture of the storage page is the same as the client-host architecture of the accessing application(s), the amount of format conversion is minimal.
Example Consider the homogenous Objectivity/DB system in Figure 15‑1. A federated database is accessed by an application running on a client host of a particular Linux architecture. The application has created all of the storage pages in the federated database using the default disk format, so the client host’s Linux architecture owns these storage pages. The application performs minimal format conversion when reading persistent objects from these pages.
Figure 15‑1 Disk and Memory Format in a Homogeneous Objectivity/DB System
In a heterogeneous Objectivity/DB system, an application of one client-host architecture may access persistent objects on storage pages owned by another architecture. Objectivity/DB supports this by automatically converting the disk format of each accessed object to an in-memory format recognized by the client-host architecture of the accessing application. Such in-memory format conversion is temporary—if the accessing application writes an existing page back to disk, the page’s original disk format is used. The overall performance impact of in-memory format conversion is usually not noticeable, because the burden of converting between architectures is spread more or less evenly among the accessing applications.
Example Consider the heterogeneous Objectivity/DB system in Figure 15‑2. The federated database from the previous example is now accessed by a second application, which runs on a client host of a particular Windows architecture. After the second application creates new storage pages using its default disk format, the federated database contains a mixture of storage pages—some owned by the Linux architecture and some owned by the Windows architecture.
When the Linux application accesses an object on a Windows page, the object is temporarily converted in memory to the Linux format. Similarly, when the Windows application accesses an object on a Linux page, the object is temporarily converted in memory to the Windows format.
Figure 15‑2 Disk and Memory Format in a Heterogeneous Objectivity/DB System
Note:The example in Figure 15‑2 is still valid if you use a Macintosh client host in place of either of the existing client hosts.
Rehosting an application to a new client-host architecture can have a noticeable impact on the application’s performance. This is because the rehosted application must now perform cross-architecture conversion every time it accesses data on the storage pages it created prior to rehosting.
Example Consider the Objectivity/DB system in Figure 15‑3. The Linux application from the previous example has been rehosted so that it now runs on a Windows client host. Rehosting the application has no effect on the owning architecture of existing storage pages, so the federated database still contains pages owned by the Linux architecture. Consequently, every time the rehosted application accesses persistent objects on those pages, the accessed objects must now be converted in memory to the Windows format. Furthermore, the performance impact of this conversion is no longer offset by a performance advantage in any application, because no application in this system has a client-host architecture that matches the owning architecture of the pages.
Figure 15‑3 Objectivity/DB System with Rehosted Application
Deciding Whether to Change Storage-Page Ownership
You can reduce the amount of in-memory format conversion a rehosted application must perform by making such format conversion permanent—that is, by changing the disk format of the federated database’s storage pages to match that of the rehosted application’s new client-host architecture.
In a case such as the previous example, where rehosting causes all accessing applications to have the same client-host architecture, you should specify that client-host architecture as the new owning architecture of the federated database’s storage pages, as described in “Changing the Ownership of Storage Pages” on page 172.
If Data is Accessed From Multiple Architectures
If a federated database is accessed by multiple applications compiled for different client-host architectures, and a majority of these applications are compiled for a particular client-host architecture, you should consider changing the storage pages so they are owned by that majority architecture.
If a federated database is accessed by applications compiled for a variety of architectures, with no single majority architecture, you may be better off leaving the disk format of existing storage pages as is. (You may still be able to improve application performance in this case by setting each application’s hot-mode property; see the documentation for your Objectivity/DB programming interface.)
Interoperating With Earlier Releases of Objectivity/DB
You should not change the owning architecture of existing storage pages in a federated database if both of the following are true:
The federated database will be accessed by both a rehosted application and an application built with an earlier release of Objectivity/DB.
The client-host architecture of the rehosted application is not recognized by the earlier application because support for the architecture was introduced in a later release of Objectivity/DB.
If you rehost an application to a newly supported client-host architecture, and you want the rehosted application to interoperate with an unrebuilt legacy application, you must change the application you are rehosting so that it writes its new storage pages using a disk format that can be recognized by the legacy application. For information about setting an application’s disk-format property, see the documentation for your Objectivity/DB programming interface.
Changing the Ownership of Storage Pages
To change the owning architecture of storage pages in a container, database, or federated database, you run ConvertFormat with the -id or -all option, and the -bootFile option. You can add the -from option to change only the storage pages currently owned by a particular architecture. By default, ownership of storage pages is changed to the architecture of the host on which you run ConvertFormat. You can add the -format option to specify the desired owning architecture explicitly. (Run ConvertFormat -listArchitectures for a list of available architectures.)
You can convert between architectures with the same addressing modes or between architectures with different addressing modes (either 32-bit or 64-bit). When converting from a 32-bit to a 64-bit architecture, some persistent objects might no longer fit in their original storage space due to an increase in the class’s size. Such an object is automatically redirected to a page with more space, and a link to its new location is maintained by a redirection stub left in the original location.