It's probably best to get a shared lock right when you tie, then upgrade it to an exclusive lock as soon as you need to write to the file and not downgrade to a shared lock from an exclusive one ever as that will jeopardize integrity.

Are there are any caveats or disadvantages which I should be aware of in acquiring and holding a shared lock for the duration of the life of the tied object?

Update - Curiously, while I would expect that a shared lock would be appropriate for the EXISTS method, the module MLDBM::Sync which perrin referred me to here actually calls upon an exclusive lock for calling upon the EXISTS method of the underlying file store.

None so long as everyone's just reading. If anyone wants to write and tries to get an exclusive lock, they'll have to wait for everyone to finish reading and untie, but that's the point of the excercise: it guarantees that you can never end up writing back out of date data. Of course you'll have to tell your users that they need to untie and forget what they've read as soon as possible, if many processes are to be simultaneously writing to that same database.

Makeshifts last the longest.

If anyone wants to write and tries to get an exclusive lock, they'll have to wait for everyone to finish reading and untie, but that's the point of the excercise: it guarantees that you can never end up writing back out of date data. Of course you'll have to tell your users that they need to untie and forget what they've read as soon as possible, if many processes are to be simultaneously writing to that same database.

Hrmmm, that makes be feel a little uncomfortable - This functional requirement sounds very much like the behaviour of Apache::Session which was, in part, why I started work on this module.

I am taking a closer look at MLDBM::Sync as suggested by perrin in this post, but would look to expand upon the relatively fixed framework on this module.