By means of locks, JRIO permits the simultaneous, synchronized processing of a file by multiple applications (shared update processing) if this is supported by the particular file system and access method.
This type of processing must be explicitly set by the application when the file is opened. It ensures that the processing steps (e.g. write, delete or a combination of read and write) are protected by locks and cannot be interfered with by competing applications. Shared update processing may be subject to file system-specific restrictions. For example, it may not be permitted for certain file types or open modes, or it may not support certain actions such as increasing or reducing the size of files.
The lock mechanism employed by JRIO in shared update processing is:
record-oriented,
implicit,
deadlock secure.
Record-oriented means that logically an application locks or releases records only within a file. However, certain file systems or access methods can physically implement a larger lock granularity. This is not visible to your own applications but competing applications may encounter a lock when they attempt to access a record within the larger lock granularity although the requested record itself is logically locked.
Implicit means that records are implicitly locked when they are read, written or deleted, and that the lock is implicitly released after the write or delete operation has been completed. Methods are also offered for the explicit release of records that are locked for reading but are not to be written.
Deadlock security is achieved by ensuring that an application can only ever logically lock one record per file. Setting a lock for an operation leads implicitly to the release of any other lock for another record. Some file systems and access methods are also able to implement deadlock security beyond file boundaries; in other words, only one lock per application is permitted - regardless of in which file.
In shared update processing JRIO allows the behavior of the application to be controlled in the event of access conflicts. The application can demand immediate transfer of control (NO_WAIT parameter). In the event of access conflicts, a corresponding exception (RecordLockedException) is then generated or the application can wait for granting of the lock as a thread (THREAD_WAIT parameter) or at the system interface (APPLICATION_WAIT parameter). The wait time is unlimited in both cases, i.e. the application waits until a lock is received or until the application itself is terminated. Waiting as a thread has the advantage that other threads of the application are not blocked. However, in extreme situations it can happen that the lock is received by a competing application at the very moment that the waiting application makes a renewed attempt although the lock was available in the meantime. Not all file systems offer all wait variants. If, however, a variant is offered, the semantics described then apply.