Redirecting Locator Files
This feature of Gateway engine operation guarantees transaction atomicity for multidirectory databases and also makes it easy to change the name of a Gateway engine across multiple data directories.
Recall that the PSQL client uses the following approach to access remote data files:
1
2
3
It is important to remember that the Gateway configuration only goes into effect when there is no database engine available on the same computer as the data files.
This feature allows a dynamic (floating) Gateway engine while at the same time preserving transaction durability for multidirectory databases on the same volume. This benefit is provided by a new type of Gateway Locator File that points to another Gateway Locator File. The new type is called a Redirecting Locator File. By having Redirecting Locator Files in directories A, B, and C that point to the Locator File in directory D, you can ensure that the Gateway engine specified by the Locator File in directory D services data files in the other directories as well.
Regardless of whether the Locator file in directory D specifies a permanent Gateway or is dynamically created by the first engine to open those files, this architecture ensures that all the specified directories use the same Gateway engine. Likewise, if you decide to change the permanently assigned Gateway engine for several directories, Redirecting Locator Files allow you to do so by changing only one Locator File, rather than all of them. Thus, it is possible to specify that all data files on a given hard drive must use the same Gateway engine, with or without designating a permanent Gateway.
Redirecting Locator File Requirements
The first line of a Redirecting Locator File must start with “=>” and be followed by a path specifying another Locator File, which must be on the same drive. You can use any combination of forward slash and back slash in the path name. All slashes are converted to the type of separator used by the local operating system.
If your specified path ends with a slash, the database engine assumes the default Locator File name (~PVSW~.LOC) and appends it to the path. If the specified path does not end with a slash, the database engine assumes that the path already contains the file name.
The following table lists the ways a Redirecting Locator File path can be specified:
=>\path_name
=>.\path_name
=>..\path_name
You can assign multiple levels of redirection to these Locator Files. For example, you can have the first Locator File pointing to a second Locator File, the second Locator File pointing to a third Locator File, and so on. Each workgroup engine opens each Locator File sequentially, looking for the actual Gateway name. It stops searching once it has found the locator file that does not start with “=>”. The engine then assumes this Locator File specifies the Gateway engine.
Creating Redirecting Locator Files
As with any Locator File, a Redirecting Locator File is a plain text file. You can create Redirecting Locator Files by hand or programmatically. A Redirecting Locator File must be flagged as read-only, or it will be overwritten by the first engine to attempt to access the data files in that directory.
1
2
For example, if you want to ensure that the data files in C:\data are accessed by the same Gateway engine as other data files, then you will want to keep in mind the folder C:\data.
3
Type in => and the path name of the next Locator File. Continuing the example from the previous step, if you want the current data files in C:\data to be owned by the Gateway engine specified in the Locator File located in c:\moredata, then you would type the following:
=>..\moredata\ (recommended) or
=>\moredata\ (not recommended)
In the first case, you are specifying a relative path from the current directory. In the second case, you are specifying an absolute path from the root of the current drive. In this particular example, both cases resolve to the same target directory.
*Note: It is strongly recommended that you use relative path names (starting with ./ or ../) in your Redirecting Locator Files, and that you use the same share names on all workstations to access the same data. Following these two recommendations can prevent errors that may occur with network path name resolution over mapped drives.
4
5
6
To mark the file as read-only on Windows, you can use the Properties dialog box (right-click the file icon) in Windows Explorer, or you can use the ATTRIB command in a DOS session or in a program:
ATTRIB +R ~PVSW~.LOC
1
For example, your locator file may specify the computer named workgroup1 as the Gateway engine, and the file may be located in C:\DATA\DB1.
2
Continuing the example, each Redirecting Locator File in C:\DATA\DB2 and C:\DATA\DB3 would then contain the following text:
=>..\DB1\
This causes any engine reading this file to follow the relative path and search the specified directory C:\DATA\DB1 for another Locator File. In this case, the specified directory contains a Locator File that names workgroup1 as the Gateway computer.
1
In this case, remember that if no engines are accessing any data files in the redirecting hierarchy, then there will be no Locator File in the target directory. This is normal. The dynamic Locator File is created each session by the first engine to access the data, and the file is deleted when the last user session ends. It is permissible to have Redirecting Locator Files that point to a data directory that has no Locator File in it. In this case, the first engine to open those data files creates the Locator File.
Example
Using the example Locator Files shown in Figure 4, the Redirecting Locator File on the left forces the database engine to go up one directory, then look in the sub-directory newdir for another Locator File with the default name (~PVSW~.LOC). This Locator File, in turn, specifies that the Workgroup engine on the computer named ntserver1 is the correct Gateway engine. As a result, the database engine on ntserver1 is used to access the data files in the directory mydir.
Figure 4 Redirecting Locator File Example