Record Locking Help ....

[Ben Duncan]

Thanks Kurt.

I am looking at modifying (heavily) tdb (Samba Team's Multi User GDBM)
in to a multi value like dbm.

It already does RECORD locking via fcntl, but also uses mmap (I am sooo in the
dark about mmap). One of the things it does is traverse locking, which in my case
is frivolous (SLAG is interactive, so you work on ONE record at a time, except for
batch mode processing).

Here is what I am thinking on the modifications:

The RECORD header will be modified to include a user id and a PID and a "lockbyte".
When a "READ" with lock is done, fcntl will be employed to "LOCK" the lock byte,
obviously if that fails, the record is in "transition" of being locked.
On success, the PID, UID and LB (LOCKBYTE) will all be set and the header rewritten and
the fcntl lock released.
The data buffer is returned to the user. If a "READ is done and it is LOCKING and
the LOCKBYTE is set, a "RECORD LOCKED BY" message will appear, giving the interactive
user an option to "VIEW" the record.

When the process that did the LOCKING, either reads a NEW record, or writes
the old record back out, the UID, PID, an LB will be cleared.

Does this sound about right?


FWIW, I am going to stub in for some extra features.
One idea is to have a secondary b-tree idx file (tdb is a key/data) so you can have 
secondary key access, a "data dictionary" file and eventually journalization.

LOL, anyone want to help with this ?

Kurt Wall wrote:
> On Sun, Aug 14, 2005 at 10:38:02AM -0500, Ben Duncan took 19 lines to write:
> 
>>Anyone got any pointers, algorithms, bookmarks to, etc., on
>>dealing with record locking in a multi user environment when writing
>>a database/file manager system?
> 
> 
> The two system calls that come to mind are fcntl() and flock().
> There is also the distinction between advisory locks, which are
> not enforced at the kernel level, and mandatory locks, which can
> be enforced at the kernel level. 
> 
> If you are trying to serialize access for mulitple concurrent users,
> the usual approach is to use semaphores, which can be shared among
> multiple processes (perhaps by declaring the semaphore in a shared
> header file).
> 
> Kurt

-- 
Ben Duncan   - VersAccounting Software LLC 336 Elton Road  Jackson MS, 39212
"Never attribute to malice, that which can be adequately explained by stupidity"
        - Hanlon's Razor