Overview

Although Temenos Transact has been successfully deployed over Multiple Applications Servers, certain peculiarities related to operating systems, performance and recovery of file locks over networked file systems have prompted the requirement to provide an alternative lock strategy for Multiple Application Server deployment. As such, the jBASE Distributed lock service is used as an alternative mechanism to the networked file system, by which locks can be propagated between servers.

The Distributed lock service simply extends the existing lock mechanisms already available within jBASE by the provision of a distributed lock interface.

The Distributed lock service can be deployed as a service executing on a dedicated server or, as is more likely, deployed on one or two of the Application Servers in the Multiple Application Server configuration.

The Distributed lock service is provided through a daemon process executing on Linux or UNIX systems or as an installable service for the Windows platform. The Distributed lock service can be initiated using either the lower case form of the executable, ‘jdls’, or the jBASE capitalized convention for process daemons, jDLS (jBASE Distributed Lock Service).

The Distributed lock service also supersedes the jRLA (jBASE Record Lock Arbiter), which provided the shared memory lock mechanism for record locks. Linux or UNIX system boot scripts should be modified to initialise the lock mechanism using the jDLS rather than the jRLA executable.

How jDLS Works?

Client processes on the Application Servers are configured to connect to the distributed lock service in order to request a lock, request the status of a lock. Once initialised the client remains connected to the distributed lock service for the remainder of the life of the client process, with all lock requests issued and acknowledged through the same connection.

The connection comprises of a TCPIP socket, which uses a network byte oriented structure to pass specific lock only information. The information for example being lock type, client port number, client process id, client thread id, etc. No application data is passed over the network and hence there is no requirement for message encryption. The use of the TCP protocol is deliberate such that any break in network service can be detected quickly and if enabled, resilience activated.

Once initialised the jBASE Distributed Lock Service process undertakes two distinct operations:

• The first operation is to initialise the shared memory lock table and then continuously monitor the lock table for orphaned locks and tidy up as required. This operation was formerly undertaken by the jRLA daemon process and effectively remains the same.

• The second operation is to initialise a socket listener for connecting clients who wish to take locks on the local system. This operation is started as a second process on Linux and UNIX system and as an additional thread on Windows.

The distributed lock listener continuously listens for client connections. When a client connection is detected a separate independent process is started that will handle all the lock requirements for the connecting client process.

Each lock server or service process once started runs as a single thread within its own process space and is completely independent from any other lock server or service process as well as the daemon listener process. This enables the lock listener service to be stopped without affecting existing lock server processes and ensures any potential lock server process failure does not affect other already executing client processes. This approach provides for a robust, scalable and easily extendable implementation, which avoids many of the complications and restrictions involved with multi-threaded servers such as forked threads, signal handling and error recovery.

One to One Relationship

The one to one process relationship ensures that either of the currently available locking strategies can handle locks. The available locking strategies are Shared memory locks and OS file locks. In one to one process, locks can be easily identified to point of origin and the release of locks will be automatic in the event of a problem with the client process or client Application Server failure.

Although the Distributed Lock Service can be deployed on dedicated servers, the more usual configuration is to deploy the Lock Service on one or two of the Application Servers in the Multiple Application Server environment. Quite often a mix of Application Servers are used whereby the most powerful Application Server is used for core processes and other Application Servers used for online processing such as enquires, etc. In this case, it is more efficient to configure the main Application Server with the Distributed lock service for the other Application Servers and use local lock processing rather than Distributed locking for the core processes. The local processes will automatically detect this configuration, such that all local lock requests will automatically use the same lock mechanism as the Distributed Lock service, whereby local and distributed locks become seamlessly integrated.