_retrieve() leaks the bareword file handle LOCK, the lock file is kept locked until some other code explicitly closes that handle. _store() closes a bareword file handle never opened there.

Yes, I realize this is a litle precarious. It relies on my code always calling _retrieve() followed by _store(() at some point. It also counts on the lock getting removed when the process. Wasn't sure how else I could get around this.

If you have two instances running in parallel, and one chooses to write (calling _store()) without prior read, while the other chooses to read (calling _retrieve()), the writer will simply damage the data on disk while the reader assumes to be safe because it holds a lock. The writer doesn't even get an error, because close lacks error checks. Instant loss of data. (And trust me in that regard, Murphy will make sure that your data is damaged at the most inconvienient moment in time, causing the maximum damage.)

Yes. Bu tin my case, the processes are always upating the existing data in the file.

I tried Storable's lock functions first. They didn't work in my case (though it entirely possible I wasn't using them right. It seemed to me that something like this was happening:

1) Process A open data file to read, puts lock on it then removes lock
+ when done
2) Process B reads data file, puts lock on it, remove it when done.
3) Process C does the same.

Now we have three different process with same data. Fine. But:

1) Process A finishes and writes to file.
2) Process D reads file.
3) Process B finishes and writes data file, overwriting A's work.
4) Process E reads file (saved by Process B).

Now Process D and E have totally different starting points.
[download]

But again, maybe I was using the lock functions wrong. Not sure.