19.1 mod_perl and DBM

Where does mod_perl fit into the picture? If you need read-only access to a DBM file in your mod_perl code, the operation is much faster if you keep the DBM file open (tied) all the time and therefore ready to be used. We will see an example of this in a moment. This will work with dynamic (read/write) database accesses as well, but you need to use locking and data flushing to avoid data corruption.

It's possible that a process will die, for various reasons. There are a few consequences of this event.

If the program has been using external file locking and the lock is based on the existence of the lock file, the code might be aborted before it has a chance to remove the file. Therefore, the next process that tries to get a lock will wait indefinitely, since the lock file is dead and no one can remove it without manual intervention. Until this lock file is removed, services relying on this lock will stay deactivated. The requests will queue up, and at some point the whole service will become useless as all the processes wait for the lock file. Therefore, this locking technique is not recommended. Instead, an advisory flock( ) method should be used. With this method, when a process dies, the lock file will be unlocked by the operating system, no matter what.

Another issue lies in the fact that if the DBM files are modified, they have to be properly closed to ensure the integrity of the data in the database. This requires a flushing of the DBM buffers, or just untying of the database. In case the code flow is aborted before the database is flushed to disk, use Perl's END block to handle the unexpected situations, like so:

END { my_dbm_flush( ) }

Remember that under mod_perl, this will work on each request only for END blocks declared in scripts running under Apache::Registry and similar handlers. Other Perl handlers need to use the $r->register_cleanup( ) method:

$r->register_cleanup(\&my_dbm_flush);

as explained in Chapter 6.

As a rule, your application should be tested very thoroughly before you put it into production to handle important data.