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.

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.

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.

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.

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.

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);

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);

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

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);

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);

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.

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;

• 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.