I am acquiring successive records from an Oracle table; immediately after a good retrieval I am marking the record as 'processed' but I find that the same record can be acquired by several users. Not using the lockfile except as a locking mechanism.

If you already have a database, why bother with locks?

Oracle offers various methods for making sure that processes don't step on each others feet. Usually, you want to do stuff in a transaction.

For example an easy way could be to UPDATE all rows that you will be processing with your PID, and then select all those that you got:

update top 10 jobs
set processed_by = ?
where processed_by is null
order by job_id
;
select * from jobs where processed_by = ?
[download]

$dbh->do("LOCK TABLES bar READ");
... get next image
$dbh->do("UNLOCK TABLES");
[download]

I found this; is it preferable to flock? I have multiple users running the same program.

Funnily enough, I found this thread on supersearch, to make sure I know what 'use' statements I need for flock, precisely because I don't want to use the database. I will keep looking for what I came for after adding my tuppence:

The scenario is that I am building an HA postgres cluster with three nodes plus DR nodes. Postgres can be configured to replicate but robust HA needs extra work (in Perl seemed best) to check the status of all nodes in the cluster and if the current node has the wrong role, to either promote it to master or demote it to standby.

But you don't want postgres to start at machine bootup in this case because you want to check the correct role first. So obviously flock rather than DB is essential - why lock at all? Because otherwise if the master goes down, all the standbys will try to assume master. So the failover program (guess what, I called it failover.pl) has to lock a file (there's a shared volume used for backup, all the nodes have access to) before running its cycle. Then if it detects no masters and promotes its node to master, the failover running on any other node, will be locked out until the count of masters goes from 0 to 1 and so the possibility of two nodes seeing no master and simultaneously promoting two masters is avoided. But using the database is not feasible in this scenario because failover.pl only does anything when the postgres master node is down.

What I meant is the frequency, i.e. how many locks per second your processes will be attempting. However, if you're already using a database, you should definitely be using its locking facilities instead of flocking a file!