Administration Tools - oolockserver

Printer-friendly version
Starts a standard lock server (a separate lock-server process) on the current workstation, optionally starting the lock server’s recovery monitor as well.
oolockserver
[{bootFilePath} [-monitor [-timeout seconds]
[-interval seconds] [-testport port]]]
[-notitle]
[-help]
Options
bootFilePath
Path to the boot file of the federated database or autonomous partition to be recovered when the lock server is started. You can specify one or more paths. If you omit a federated database or autonomous partition that is serviced by the lock server, that federated database or autonomous partition is recovered the first time it is accessed by an application.
If -monitor is specified, bootFilePath also indicates the federated database for which transactions are to be monitored. If bootFilePath lists multiple paths, only the first path is used by the recovery monitor.
-monitor
Enables the lock server’s recovery monitor for the first (or only) federated database specified by bootFilePath. If bootFilePath is not specified, the -monitor option has no effect.
The recovery monitor is a thread within the lock server that periodically identifies the transactions against the specified federated database and checks whether these transactions still belong to processes on operational client hosts. If the recovery monitor determines that any client host has failed (for example, due to machine or network problems), the lock server automatically recovers all transactions started by processes on that host (equivalent to running the oocleanup tool with the -deadhost option). The recovery monitor also recovers incomplete transactions started by processes (on any client host) that are known to no longer be running.
The recovery monitor’s behavior is controlled by the -timeout, -interval, and -testport options.
-timeout seconds
Number of seconds that the recovery monitor should wait to receive a response from a client host before concluding that the host has failed (for example, due to machine or network problems). If you omit this option, the recovery monitor waits 30 seconds.
The specified value should be at least as long as the network timeout period used by the client applications (see the documentation for your Objectivity/DB programming interface).
This option has no effect unless both the -monitor option and bootFilePath are specified.
The recovery monitor checks whether a client host is operational by attempting to make a network connection to the host and waiting for a response within the specified timeout period.
-interval seconds
Number of seconds that the recovery monitor should wait before it checks again for dead client hosts. If you omit this option, the recovery monitor attempts to contact client hosts with active transactions every 60 seconds.
This option has no effect unless both the -monitor option and bootFilePath are specified.
-testport port
TCP/IP port number through which the recovery monitor attempts to contact each client host to check whether the host is operational. The same port number is used on all client hosts.
If you omit this option, the lock-server port is used. (This is the port number currently used by remote applications when communicating with the lock server.) This port number is normally sufficient, although at some sites you may need to specify a different port number—for example, to get through a network firewall. The port is used only to establish contact; no data is read or written through it, and it is not necessary for a lock server to be running on that port.
This option has no effect unless both the -monitor option and bootFilePath are specified.
-notitle
Suppresses the copyright notice and program title banner. Useful when invoking the tool from another tool or product.
-help
Prints the tool syntax and definition to the screen.
Discussion
Restarting the lock server after a lock-server failure performs automatic recovery on the federated databases specified by bootFilePath.
On Windows, you normally start the lock server from an Objectivity Network Services tool, rather than using oolockserver.exe from a command prompt. You need administrator privileges to use this tool because the lock server is started as a service, not as a user program.
Note:
If you run this tool on Windows Vista, a Windows Vista security-feature called User Account Control (UAC) will prevent you from viewing its output.
A lock server grants locks on resources (containers, databases, or federated databases) to requesting transactions. Each transaction can lock multiple resources, and a given resource can be locked by multiple transactions.
In general, a lock server cannot be started on a workstation that is already running a lock server (either a standard lock server or an IPLS application). However, it is possible for a lock server from the current release of Objectivity/DB to run on the same workstation as a lock server from certain older releases of Objectivity/DB. If a federated database specifies such a workstation as its lock-server host, you must guarantee that all applications accessing that federated database have been built with the same release of Objectivity/DB (so that they will all contact the same lock server).
Warning: Data corruption will occur if two applications built with different releases contact different lock servers while accessing data in the same federated database.

Date: 
Tuesday, October 30, 2012
Product: 
Objectivity/DB
Version: 
10.2.1
10.2
10.1.4
10.1.2
9.4.1