19.4. Locking Wrappers Overview
Here are the pros and cons of the DBM file-locking wrappers available from CPAN:
- Tie::DB_Lock
-
A DB_File wrapper that creates
copies of the DBM file for read access,
so that you have a kind of multiversioning concurrent read system.
However, updates are still serial. After each update, the read-only
copies of the DBM file are recreated. Use this wrapper in situations
where reads may be very lengthy and therefore the write starvation
problem may occur. On the other hand, if you have big DBM files, it
may create a big load on the system if the updates are quite
frequent. This module is discussed in the next section.
- Tie::DB_FileLock
-
A DB_File wrapper that
has the ability to lock and unlock the
database while it is being used. Avoids the tie-before-flock problem
by simply retying the database when you get or drop a lock. Because
of the flexibility in dropping and reacquiring the lock in the middle
of a session, this can be used in a system that will work with long
updates and/or reads. Refer to the
Tie::DB_FileLock manpage for more information.
- DB_File::Lock
-
An extremely lightweight DB_File
wrapper that simply flocks an external lock file before tying the
database and drops the lock after untying. This allows you to use the
same lock file for multiple databases to avoid deadlock problems, if
desired. Use this for databases where updates and reads are quick,
and simple flock( ) locking semantics are enough.
Refer to the DB_File::Lock manpage for more
information.
On some operating systems (FreeBSD, for example), it is possible to
lock on tie:
tie my %t, 'DB_File', $DBM_FILE, O_RDWR | O_EXLOCK, 0664;
and release the lock only by untying the file. Check if the
O_EXLOCK flag is available on your operating
system before you try to use this method!
 |  |  |
| 19.3. Flawed Locking Methods |  | 19.5. Tie::DB_Lock |
Copyright © 2003 O'Reilly & Associates. All rights reserved.