Learn about record locking in jBASE

Welcome to Locking in jBASE learning unit.
In this learning unit, you will learn why

locking is important while inputting records in T24. How locking helps in multi-user
environment in T24.
JBS5.Locking IN jBASE-R15 1
At the end of the session you will have adequate knowledge to understand,
Locking mechanism in jBASE using,
jRLA
jBASE Record Lock Arbiter
This is used if started
OS Locking
This is used when jRLA is not running
Always used for J3 files, stub files & network friendly J4s
jRLA not available on Windows (jBASE 4.0)
jRLA cannot be used in multi application server environment
Future Locking mechanisms
jDLS
Distributed Locking Arbiter
Provides jRLA functionality and lock propagation
Removes need for NFS – Network File System
What is record locking?
Assume you open a record 101024 in the CUSTOMER application using function ‘I’.
Will some one else be able to open the same record using function ‘I’ at the same
time?
NO.
How do we ensure that 2 people don’t open the same record at the same time? This is
achieved using the concept of record locking. Whenever an application (T24 in our
case) instructs the database (jBASE in our case) that it wishes to have exclusive
access to a record (This is achieved using functions I,A,D and R), the database, marks
that particular record for exclusive access and then releases it to the user. This record
remains locked until the time,
1. The record is written back into the file
2. The record is deleted
3. The program in the application that asked for the lock either terminates normally or
abnormally
4. The program in the application that asked for the lock explicitly says ‘RELEASE’
so that the lock can get released
All locks held within a transaction are released after the transaction is committed or
aborted
Can I lock a record that does not exist?
It is possible in jBASE, but not in any other database.
JBS5.Locking IN jBASE-R15
In jBASE-R12.01 3
This happens when you try to open a new record in any application in T24. Though a record
with the ID that you see in the front end does not exist, jBASE locks it so that the id is not
assigned to any other user at the same time. Try to open a new customer record using function
‘I’. Keep the screen open and try to open the same customer record from another session.
Enjoy.
Invocation of a record lock is normally due to program execution of the READU
statement
This statement requests an exclusive lock ‘FOR UPDATE’ be taken for a
specific record key within a specific file. Note unlike RDBMS models the
record/row does not have to already exist to be locked.
Binary locks normally taken as OS file locks and hence the release of these locks
occur when either
(1) Process explicitly releases the locks
(2) Process is fatally interrupted and stopped, whereby the OS automatically
releases all associated resource, i.e. Any file locks.
jRLA – jBase Record Locking Arbiter is now obsolete
When a lock is taken, the ID of the record is put through a hashing algorithm to give an
arbitrary byte address
A single byte with the address given is then locked in the file using an Operating
System lock. It does not matter whether or not the byte address actually exists in the
file
If the byte is already locked,
If there is a LOCKED clause of the BASIC statement, it will be invoked
Otherwise, the OS will block until the lock is freed
What is this offset that we are referring to?

Offset is the address of a byte that is returned by the hashing algorithm. Using this
offset, we will be able to lock a specific byte in a file.
As you can see in the above diagram, the byte offset (a particular byte to be precise) is
getting locked.
An operating system lock is then taken on the single byte identified by the byte
address. If this byte was already locked, this call would fail, and the LOCKED clause
would be invoked.
It is possible for the hashing algorithm to return a byte address that is larger than the
size of the file, particularly in the case of a stub file when using RDBMSs such as
Oracle or DB2. The OS will lock the address regardless of whether it appears in the
file.
OS Locking mechanism has it’s own advantages and disadvantages,
Let’s see advantages first,
No daemon to fail
• No exclusive access required for lock structure

• No shared memory required for locks
• Standard OS lock mechanism
• Used by third party products. i.e. Samba.
• OS file locks can be used via NFS for Multiple Application Servers
• Locks can be propagated by underlying file system
• e.g. NFS – Network File System.
• Locks are automatically released on process crash
• Some caveats for Network File Systems
• Requires physical file and handle on which to take lock
• Locks can not be abstracted. e.g. No locks on directory ‘records’
• File must remain open for entire duration of lock
• Closure of the file irrespective of duplicate file handles will release all OS
file locks. Not viable for jBASE 4.0 prior to 4.0.7
• Restricted interface
• Can either take the lock or not.
• Only obtainable information is the pid (Process Id) of process currently
holding the lock. Windows not even that.
• Process only based locks
• Cannot be used to take locks for multiple threads in same process
• Some platforms have low defaults for number OS file locks and OS file handles
• nflocks , maxfiles
As you can see above, the SHOW-ITEM-LOCKS command can only give us very
limited information.
You know that browser is stateless meaning, user doesn’t have control over to which
application server request should reach. When user opens a customer record to input
the request may go to Application Server 1 when the same user tries to commit the
record which he/she has inputted just now the request may go to Application Server 2.
The very important point here to understand is even if multiple application servers are
setup there will be only one copy of data files. That is only one copy of bnk.data
should exist and this directory gets NFS mounted so that all application servers can
have access to the same data.
Are you wondering why or what an NFS mount is?
NFS stands for network file system mount. Just like how we share directories on
windows, if we wish to share data that resides on a Unix server, we use the NFS
functionality. Among the many different file systems that FreeBSD supports is the
Network File System, also known as NFS. NFS allows a system to share
directories and files with others over a network. By using NFS, users and programs
can access files on remote systems almost as if they were local files. NFS consists
of at least two main parts: a server and one or more clients. The client remotely
accesses the data that is stored on the server machine.
As you can see above, in a multi application server setup, the bnk.data directory that
holds the stub files cannot reside on every application server. Hence, the bnk.data
directory is placed on any one of the database server and is NFS mounted so that
all application servers share the data.
Locking Flow
1. OS lock held on a byte of the CUSTOMER file. Byte calculated based on the ID and
the file name
2. Record locking information in F.RECORD.LOCK - USER 1 has locked record 1001
in the CUSTOMER file
3. Record fetched from the database. The locking information is not maintained at the
database level as T24 does not instruct the database to lock the record (though the
byte address of the record is actually locked). If any other process is trying to
access the same record whose byte address is already locked, then the file
F.RECORD.LOCK is checked to know the already existing locks.
4. Release the record to the user.
1. OS lock held on a byte of the CUSTOMER file. Byte calculated based on the ID
and the file name
2.Record locking information in F.RECORD.LOCK-USER 1 has locked record 1001 in
the CUSTOMER file
T24 updates locking information in a file F.RECORD.LOCK. Whenever record is
written to the disk the relevant entry from F.RECORD.LOCK gets released to indicate
the lock on the record is released.
You can forcefully release the record from F.RECORD.LOCK by verifying a locked
record in RECORD.LOCK application which in turn will delete the corresponding
record from F.RECORD.LOCK. This option need to be used with care to avoid data
inconsistency use this option only to release stale locks or dead locks.
What if the server which has bnk.data directory NFS mounted failed?
Although T24 has been successfully deployed over Multiple Applications Servers
certain idiosyncrasies 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 the T24 Multiple Application Server deployment. As such
the jBASE Distributed lock service is now offered 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 the T24 Run Time Application Infrastructure (RTIA) by the provision of
a distributed lock interface to the T24 Application Servers.
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 via a daemon process executing on Linux/Unix
systems or as an installable service for the Windows platform.
The Distributed lock service also supersedes the jRLA, (jBASE Record Lock Arbiter),
which provided the shared memory lock mechanism for record locks. Linux/Unix
system boot scripts should be modified to initialise the lock mechanism using the jDLS
rather than the jRLA executable.
T24 Client processes on the Application Servers are configured to connect to the
distributed lock service in order to request a lock be taken, request the status of a lock
or request locks be released. 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 TCP/IP 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
JDLS is a new environment variable that can be set in the .profile or remote.cmd as
the case may be, on both the application servers that must act as primary and
secondary lock servers.
JDLS={SERVER=Hostname{, Port}}{,SERVER2=Hostname{, Port}}
Where:
SERVER=Hostname Specifies the IP or the host name of the T24

application server that is to act as a primary lock server
Port Is the socket port number (default 50002) on which
the jBASE Distributed Lock Service is listening.
SERVER2 Specifies the IP or the host name of the T24
application server that is to act as a secondary lock server
Port Is the socket port number (default 50002) on which
the jBASE Distributed Lock Service is listening.
Note: The above specifications are completely optional as denoted by the braces,
although SERVER2 specification has no meaning without specification of SERVER. If
SERVER is not specified but the JDLS environment is set then the configuration will
default to ‘localhost’ and port 50002.
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 exactly 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/service process once started runs as a single thread within its own
process space and is completely independent from any other lock server/service
process as well as the daemon listener process. This enables the lock listener service
to be stopped without impacting existing lock server processes and also ensures any
potential lock server process failure does not impact 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.
Command to start jDLS on windows:
jServControl –v –s manual –p%JBCRELEASEDIR%\bin\jDLS.exe jDLS start
Command to stop jDLS on windows:

jServControl –v –s manual –p%JBCRELEASEDIR%\bin\jDLS.exe jDLS stop
Command to remove jDLS from windows:

jServControl –v –s manual –p%JBCRELEASEDIR%\bin\jDLS.exe jDLS remove
The output above clearly shows that jDLS is using the jRLA way of locking. Notice the
‘Locking Mechanism’ section. To access a group, we require semaphores. Refer the
jRLA section for more information on this. It now shows that there are 151 groups and
there can be a maximum of 3020 locks held at a time across these groups. Each
group can contain 20 locks.
When a user issues a request to lock a record, the request, as usual passes through the
network dispatcher and the web server.
We configure our T24 application servers to what is known as a ‘Primary Server’ and
‘Secondary Server’ to hold lock information. As the name implies, the server configured as the
primary server is the one that will serve all lock requests. Once done, jDLS will ensure that the
lock information is propagated to the secondary server. How we configure these servers as
primary and secondary, we will learn as we proceed.
So, the request will always hit the primary server first.
At the primary server:
The jDLS lock service running on the server allocates a dedicated server process to
act as a lock proxy for the client thread.
The client and server communicate over sockets using the TCP/IP protocol for the
duration of the client session. Using this mechanism we
Ensure client session can continue irrespective of service listener
Ensure any server failure only detrimental to specific client
If at all the client thread fails, the server proxy process will release all locks associated
with the client. WOW .
As mentioned earlier, The client process can be configured for resilience to avoid a single point
of failure of the jBASE distributed lock service. In resilient mode the client process
communicates sequentially with two lock service processes, a primary and a secondary,
executing on separate systems The client issues the lock request to the primary lock server. If
the result from the primary system is successful, the client then issues the same lock request to
the secondary server. If the lock requests results mismatch an error is logged but the client
process continues assuming the primary server is correct. If the request to the primary server
fails (host down) then the client automatically promotes the secondary server to become the
primary server and all future lock requests will only be issued to the surviving lock server. At this
point resilience is no longer enabled.
Lets try to open an existing record through the primary application server and then
execute the SHOW-ITEM-LOCKS to list out the locks details.
The lock information shows that the record has been locked by primary application
server (10.92.1.250)
Now let’s open the same record through the secondary application server, and
similarly list out the locks by executing the SHOW-ITEM-LOCKS.
The record opens in READ-ONLY mode and the lock information clearly states that
the record is locked by the primary server (10.92.1.250).
Doesn’t this hold much more information than just the port number which we saw
when OS locking was used?
Windows : The LOCK# value that you see is the value that is calculated based on the
ID of the record, Inode number and the device name of the file.
Unix
10.44.1.56 is configured as the jDLS server.
Port 2 is a local process on the same system as the jDLS server(10.44.1.56) 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.55. It is communicating with the lock
server process with process ID 15031. Process 15031 is the dedicated lock process
for the client on port 1000
Now, will you be able to explain the last line of output? (127.0.0.1….)
Remember : 127.0.0.1 is a loop back address.
Scalability is the ability of a system, network, or process, to handle growing amount of
work in a capable manner or its ability to be enlarged to accommodate that growth. For
example, it can refer to the capability of a system to increase total throughput under an
increased load when resources (typically hardware) are added.
The scaling of database can be thought of in two ways Horizontal and Vertical. In
vertical scaling we run database server with more CPU’s thereby dividing task
between the CPU of the same machine. Vertical scaling is more depends on
multithreaded architecture of the Database
To scale horizontally means to add more nodes to a system, such as adding a new
computer to a distributed software application. An example might be scaling out from
one Web server system to three.
The vertical scaling can be achieved in jBASE by increasing the number of CPUs,
there by increasing the number of tSAs that can be active at any given point.
Increasing the number of tSA’s will have a huge performance advantage in COB.
Horizontal scaling can be achieved by adding more application servers / database
servers in parallel to increase the performance.
1. It has been noticed that with many clients, jBASE appears to stop scaling vertically,
especially on machines with Unix type operating system.
On a typical client installation setup we will have 100s of Hash files spread across the
disk with 100s of processes trying to access and update them in parallel.
To explain the scalability problem, let us assume an environment, where

‘N’ processes are trying to update a table with ‘X’ number of records takes time ‘T’,
then
with ‘N * 2’ processes, it should ideally take time ‘T/2’
with ‘N * 4’ processes, it should take ‘T/4’ and so on.
But jBASE does not scale like this, even on capable hardware. Identified problem
seems to be that when multiple agents attempts to accesses the same file, Unix kernel
takes a special lock on the group header called as advisory or Group Locks. These
locks are stored in linked lists. Therefore, for large number of processes accessing
tables, we end up in creating a huge linked list that can become a bottleneck for our
scalability.
In R12, the OS Native/Advisory locking mechanism is changed into a POSIX based

semaphore locking, in order to handle the jBASE scalability issue. In this mechanism,
when a lock is identified as group header lock, the locking information is stored in a
shared memory table. Shared memory table is an area in memory where the details of
a lock like pid, inode number, device number, time stamp are stored. The position of
each lock in the table is identified with the help of a hashing algorithm.
This POSIX based locking mechanism can be activated or deactivated using the following
environment variable.
To activate : export JBASE_GROUP_LOCK=1

To deactivate : unset JBASE_GROUP_LOCK
1. TRUE
2. FALSE
3. TRUE
4. TRUE
In this learning unit you learnt,
Locking Mechanism in jBASE using,
OS Locking
This is used when jRLA is not running
Always used for j3 files, stub files & network friendly j4s
jRLA not available on Windows (jBASE 4.0)
jRLA cannot be used in multi application server environment
Future Locking mechanisms
jDLS
Distributed Locking Arbiter
Provides jRLA functionality and lock propagation
Removes need for NFS

Learn about record locking in jBASE

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Learn about record locking in jBASE

Uploaded by

Copyright:

Available Formats

Welcome to Locking in jBASE learning unit.

In this learning unit, you will learn why

What is this offset that we are referring to?

• No exclusive access required for lock structure

JDLS={SERVER=Hostname{, Port}}{,SERVER2=Hostname{, Port}}

SERVER=Hostname Specifies the IP or the host name of the T24

Command to stop jDLS on windows:

Command to remove jDLS from windows:

Remember : 127.0.0.1 is a loop back address.

To explain the scalability problem, let us assume an environment, where

In R12, the OS Native/Advisory locking mechanism is changed into a POSIX based

To activate : export JBASE_GROUP_LOCK=1

You might also like