Post by Hein RMS van den Heuvel
fwiw - RMS will typically do at least one often more locks per direct IO on a shared files.
The core (VBN) lock to be one to protect others from reading updated data while in transit.
I've become quite fond of mapping the whole file section into memory,
if speed is a requirement.
Depending on local requirements, flush the section or flush the changes
to backing store, or implement journaling.
Using a database and potentially an in-memory database is the usual
approach for those that don't want to write this code.
SQLite is one that's available on OpenVMS—that'll still use locks for
coordination, so prototyping the performance would be wise.
The other approach is sharding; of splitting up the I/O activity and
usually of sending the user to the data and not the data to the user.
Sharding the data gets yet more interesting with clustering, as the
coordination overhead is inherently larger in clustered configurations.
But as mentioned earlier, collect and track the performance, as that'll
usually reduce the numbers of production-relevant performance surprises.
Pure Personal Opinion | HoffmanLabs LLC