Sounds like locking discipline is not being followed consistently.
lock (or die, or wait and retry -- a blocking lock will do this for you) open db file (or wait and retry) manipulate db file (or gracefully handle out-of-space) close db file (or die - very odd. You opened it didn't you?) release lock (or die - again very odd. You got the lock didn't you?)
all the time. Perl database tieing _DOES NOT_ do that, although writing a wrapper that takes some database file tieing arguments and a lock file name and wraps the safe five-step procedure up inside FETCH and STORE is trivial if you can write a TIEHASH.
And if your data accesses are all abstracted into a TIEHASH that you maintain, you can plug in a different persistence model, or tune (atomicity of updates? caching recent values?) the one you are using, very easily, by rewriting your TIEHASH.
That will keep your data stable under CPU load. Think of locking discipline like traffic light discipline, only instead of lives and fenders being it stake it is data integrity.
Matt Sergeant wrote:[...] very "weird" stability issues with db files of all varieties (even DB_File). Especially under extreme load. I've had much better success with SQLite.
