19.4 Database File System (DBFS)— POSIX File Locking

Starting from Oracle Database 12c Release 2(12.2), Oracle supports the Database File system POSIX File locking feature.

The DBFS provides file locking support for the following types of applications:

• POSIX applications using DBFS_CLIENT (in mount mode) as a front-end interface to DBFS.

  See Also:

  DBFS Client Access Methods

• Applications using PL/SQL as an interface to DBFS.

Note:

Oracle supports only Full-file locks in DBFS. Full-file lock implies locking the entire file from byte zero offset to the end of file.

• About Advisory Locking
  Advisory locking is a file locking mechanism that locks the file for a single process.
• About Mandatory Locking
  Mandatory locking is a file locking mechanism that takes support from participating processes.
• File Locking Support
  Enabling the file locking mechanism helps applications to block files for various file system operations.
• Compatibility and Migration Factors of Database Filesystem—File Locking
  The Database Filesystem File Locking feature does not impact the compatibility of DBFS and SFS store provider with RDBMS.
• Examples of Database File System—File Locking
  These examples illustrate the advisory locking and the locking functions available on UNIX based systems.
• DBFS Locking Behavior
  This section describes the DBFS locking behavior.
• Scheduling File Locks
  DBFS File Locking feature supports lock scheduling.

19.4.1 About Advisory Locking

Advisory locking is a file locking mechanism that locks the file for a single process.

File locking mechanism cannot independently enforce any form of locking and requires support from the participating processes. For example, if a process P1 has a write lock on file F1, the locking API or the operating system does not perform any action to prevent any other process P2 from issuing a read or write system call on the file F1. This behavior of file locking mechanism is also applicable to other file system operations. The processes that are involved (in file locking mechanism) must follow a lock or unlock protocol provided in a suitable API form by the user-level library. File locking semantics are guaranteed to work as per POSIX standards.

19.4.2 About Mandatory Locking

Mandatory locking is a file locking mechanism that takes support from participating processes.

Mandatory locking is an enforced locking scheme that does not rely on the participating processes to cooperate and/or follow the locking API. For example, if a process P1 has taken a write lock on file F1 and if a different process P2 attempts to issue a read/write system call (or any other file system operation) on file F1 , the request is blocked because the concerned file is exclusively locked by process P1.

19.4.3 File Locking Support

Enabling the file locking mechanism helps applications to block files for various file system operations.

The fcntl(), lockf(), and flock() system calls in UNIX and LINUX provide file locking support. These system calls enable applications to use the file locking facility through dbfs_client-FUSE callback interface. File Locks provided by fcntl() are widely known as POSIX file locks and the file locks provided by flock() are known as BSD file locks. The semantics and behavior of POSIX and BSD file locks differ from each other. The locks placed on the same file through fcntl() and flock() are orthogonal to each other. The semantics of file locking functionality designed and implemented in DBFS is similar to POSIX file locks. In DBFS, semantics of file locks placed through flock() system call will be similar to POSIX file locks (such as fcntl()) and not BSD file locks. lockf() is a library call that is implemented as a wrapper over fcntl() system call on most of the UNIX systems, and hence, it provides POSIX file locking semantics. In DBFS, file locks placed through fcntl(), flock(), and lockf() system-calls provide same kind of behavior and semantics of POSIX file locks.

Note:

BSD file locking semantics are not supported.

19.4.4 Compatibility and Migration Factors of Database Filesystem—File Locking

The Database Filesystem File Locking feature does not impact the compatibility of DBFS and SFS store provider with RDBMS.

DBFS_CLIENT is a standalone OCI Client and uses OCI calls and DBMS_FUSE API.

Note:

This feature will be compatible with OraSDK/RSF .

19.4.5 Examples of Database File System—File Locking

These examples illustrate the advisory locking and the locking functions available on UNIX based systems.

The following example uses two running processes — Process A and Process B.

Example 19-2 No locking

Process A opens file:

file_desc = open(“/path/to/file”, O_RDONLY); 
/* Reads data into bufffers */ 
read(fd, buf1, sizeof(buf)); 
read(fd, buf2, sizeof(buf));
close(file_desc);

Subjected to OS scheduling, process B can enter any time and issue a write system call affecting the integrity of file data.

Example 19-3 Advisory locking used but process B does not follow the protocol

Process A opens file:

file_desc = open(“/path/to/file”, O_RDONLY); 
ret = AcquireLock(file_desc, RD_LOCK); 
if(ret) 
{ 
	read(fd, buf1, sizeof(buf)); 
	read(fd, buf2, sizeof(buf)); 
	ReleaseLock(file_desc); 
} 
close(file_desc);

Subjected to OS scheduling, process B can come in any time and still issue a write system call ignoring that process A already holds a read lock.

Process B opens file:

file_desc1 = open(“/path/to/file”, O_WRONLY); 
write(file_desc1, buf, sizeof(buf)); 
close(file_desc1);

The above code is executed and leads to inconsistent data in the file.

Example 19-4 Advisory locking used and processes are following the protocol

Process A opens file:

file_desc = open(“/path/to/file”, O_RDONLY); 
ret = AcquireLock(file_desc, RD_LOCK); 
if(ret) 
{
	read(fd, buf1, sizeof(buf)); 
	read(fd, buf2, sizeof(buf)); 
	ReleaseLock(file_desc);
}
close(file_desc);

Process B opens file:

file_desc1 = open(“/path/to/file”, O_WRONLY); 
ret = AcquireLock(file_desc1, WR_LOCK); 
/* The above call will take care of checking the existence of a lock */ 
if(ret) 
{ 
	write(file_desc1, buf, sizeof(buf)); 
	ReleaseLock(file_desc1); 
} close(file_desc1);

Process B follows the lock API and this API makes sure that the process does not write to the file without acquiring a lock.

19.4.6 DBFS Locking Behavior

This section describes the DBFS locking behavior.

The DBFS File Locking feature exhibits the following behaviors:

• File locks in DBFS are implemented with idempotent functions. If a process issues “N” read or write lock calls on the same file, only the first call will have an effect, and the subsequent “N-1” calls will be treated as redundant and returns No Operation (NOOP).

• File can be unlocked exactly once. If a process issues “N” unlock calls on the same file, only the first call will have an effect, and the subsequent “N-1” calls will be treated as redundant and returns NOOP.

• Lock conversion is supported only from read to write. If a process P holds a read lock on file F ( and P is the only process holding the read lock), then a write lock request by P on file F will convert the read lock to exclusive/write lock.

19.4.7 Scheduling File Locks

DBFS File Locking feature supports lock scheduling.

This facility is implemented purely on the DBFS client side. Lock request scheduling is required when client application uses blocking call semantics in their fcntl(), lockf(), and flock() calls.

There are two types of scheduling:

• Greedy Scheduling

• Fair Scheduling

Oracle provides the following command line option to switch the scheduling behavior.

Mount -o lock_sched_option = lock_sched_option Value;

Table 19-1 lock_sched_option Value Description

Value	Description
1	Sets the scheduling type to Greedy Scheduling. (Default)
2	Sets the scheduling type to Fair Scheduling.

Note:

Lock Request Scheduling works only on per DBFS_CLIENT mount basis. For example, lock requests are not scheduled across multiple mounts of the same file system.

• Greedy Scheduling
  In this scheduling technique, the file lock requests does not follow any guaranteed order.
• Fair Scheduling
  The fair scheduling technique is implemented using a queuing mechanism on per file basis.

19.4.7.1 Greedy Scheduling

In this scheduling technique, the file lock requests does not follow any guaranteed order.

Note:

This is the default scheduling option provided by DBFS_CLIENT.

 If a file F is read locked by process P1, and if processes P2 and P3 submit blocking write lock requests on file F, the processes P2 and P3 will be blocked (using a form of spin lock) and made to wait for its turn to acquire the lock. During the wait, if a process P4 submits a read lock request (blocking call or a non-blocking call) on file F, P4 will be granted the read lock even if there are two processes (P2 and P3) waiting to acquire the write lock. Once both P1 and P4 release their respective read locks, one of P2 and P3 will succeed in acquiring the lock. But, the order in which processes P2 and P3 acquire the lock is not determined. It is possible that process P2 would have requested first, but the process P3’s request might get unblocked and acquire the lock and the process P2 must wait for P3 to release the lock.

19.4.7.2 Fair Scheduling

The fair scheduling technique is implemented using a queuing mechanism on per file basis.

For example, if a file F is read locked by process P1, and processes P2 and P3 submit blocking write lock requests on file F, these two processes will be blocked (using a form of spin lock) and will wait to acquire the lock. The requests will be queued in the order received by the DBFS client. If a process P4 submits a read lock request (blocking call or a non-blocking call) on file F, this request will be queued even though a read lock can be granted to this process.

DBFS Client ensures that after P1 releases its read lock, the order in which lock requests are honored is P2->P3 -> P4.

This implies that P2 will be the first one to get the lock. Once P2 releases its lock, P3 will get the lock and so on.