Utilities

This section explains about the SHOW-ITEM-LOCKS utility. It can be referenced by other program names to display record lock information.

The jDLS executable can also be used directly to display the shared memory lock table information, but is unable to display associated file or table name information.

SHOW-ITEM-LOCKS

The SHOW-ITEM-LOCK utility includes the IP address of the port when displaying information. The utility allows to obtain the lock information for each port from the JBCRELEASEDIR/proc/info directory when either the jDLS Lock Service is deemed active on the system or the client JDLS environment variable is configured, thus enabling the utility to be executed from a remote client system.

Below is the show-item-locks information retrieved from process information entries generated in the JBCRELEASEDIR/proc/info directory on host 10.44.1.56.

IPADDR    PORT   PID   FILENAME        RECORD KEY   LOCK#              PORT/-PID
0.0.0.0    2      15071 ac/FBNK.ACCOUNT 32549        0x58ba67d8,W       ---
10.44.1.55 1000   15031 ac/FBNK.ACCOUNT 33537        0x0df361bc,W       ---
127.0.0.1  4      15112 ac/FBNK.ACCOUNT USD163170001 0x6bc61286,W       ---

Where,

• Port 2 is a local process on the same system as the jDLS server and hence has a dotted address of 0. This process (pid 15071) takes locks directly on the same server.

• Port 1000 is a remote client (on system 10.44.1.56) with the JDLS environment variable configured as JDLS=SERVER=10.44.1.56. The client process is communicating with the lock service (jDLS) on the lock server system (10.44.1.56) and has an associated lock server process (15031). The dotted host address of the client system (10.44.1.55) is displayed by show-item-locks. The jDLS lock server process (pid 15031) has taken the lock on record key 33537 on behalf of the remote client on port 1000 executing on the remote system (10.44.1.55).

• Port 4 is another local process on the same system as the active jDLS server but has also been configured with a jDLS environment variable. This time the variable is set to use the default configuration and as such this process is using the reserved loop back local host address of 127.0.0.1.

jDLS –dvL

In the above case, the shared memory lock mechanism was deployed as the default locking mechanism.  As such the shared memory lock table information can also be displayed using the –dvL command line options to the jDLS executable. For example,

Executon of the jDLS command with the –dvL option on system 10.44.1.56.

jDLS –dvL
 
Lock monitor at pid:      14960 - Active
Lock listener at pid:     14961 - Active
Program started:          Thu Apr 27 17:28:17 2006
Time last ran:            Thu Apr 27 18:26:30 2006
Time last tidied up:      Thu Apr 27 18:23:50 2006
Lock retries:             0
Tidy-up time:             5 minutes
Locking mechanism:        IPC semaphores based on THREAD id
Tidy-up operations:       0
Semaphore IDs:            1441792,  1474561
Memory:                   6624 bytes used , 128544 bytes free
CPU Usage:                0.09 usr , 0.09 sys
Record locks outstanding
Group value      pid     type  port i-node   dev queued ipaddr      key
89    0x0df361bc 15031   WRITE 1000 01483651 -1  None   10.44.1.55  33537
161   0x6bc61286 15112   WRITE 4    01483651 –1  None   127.0.0.1   USD163170001
189   0x58ba67d8 15071   WRITE 2    01483651 -1  None   0.0.0.0     32549
Record locks:        13150 locks maximum in 263 groups of 50 locks/group
                     3 locks currently in use
                     1 is max. locks found in one group

This display shows similar information to the show-item-lock utility, however the file name information is not held within the shared memory lock table, only the associated inode. Also note the device information is defaulted to minus one as the values for the devices for the mounted file partitions can vary between application servers and hence cannot be used.

Additional information regarding the process and status of the Distributed Lock Monitor and the Distributed Lock Listener processes is displayed along with the time the Lock service was started.  For the Windows platform, the process numbers for the two function would be the same as the Lock Monitor and the Lock Listener run as different threads within the same process.

Lock Server Processes

In the previous example of three locks, the following lock service processes are in use on the lock server system (10.44.1.56).

ps –ef | grep jdls 
locks         14960     1  0 17:28 ?        00:00:00 jdls -ib
locks         14961 14960  0 17:28 ?        00:00:00 jdls -ib
locks         15031 14961  0 17:29 ?        00:00:00 jdls -ib
locks         15112 14961  0 17:41 ?        00:00:00 jdls -ib

Where,

• The lock service has been started as user ‘locks’.

• Process 14960 is executing as the Distributed Shared Memory Lock Monitor.

• Process 14961 is executing as Distributed Lock Listener Service.

• Process 15031 is executing on behalf of Port 1000 on client 10.44.1.55.

• Process 15112 is executing on behalf of Port 4 on local host 10.44.1.56.

As can be seen from the utility displays, Port 2 is executing on the same local system as the distributed lock service (10.44.1.56) on process 15071 and taking locks directly in the shared memory lock table.

ps –ef | grep 15071 
betatest 15071 15064  0 17:30 pts/2    00:00:00 ED FBNK.ACCOUNT 32549

This example demonstrates the integration capabilities of the Distributed Lock Service whereby the distributed lock configuration can be adjusted to take best advantage of system topology. For example, a 32 CPU system mixed with a couple 4 CPU systems could be allocated to form the Application Server tier. The lock service can be configured such that Distributed Lock Service executes on the 32 CPU system such that lock intensive processing jobs like the COB, which would probably be best scheduled to run on the larger server, can run using the standard direct lock mechanisms avoiding network requirement for lock requests, whereas other online or interface processes could be enabled to process on the smaller application servers and hence configured to communicate with the Distributed Lock Service for their lock requirements. The Distributed Lock Service is fully compatible with the existing lock mechanisms and hence the disparate systems can be fully integrated to coordinate lock activity.