I still suggest you just swap direct DB_File for MLDBM::Sync. What you have seems like a locking issue, but without looking at the rest of your code, it's very hard to find it. You should keep in mind that not all of the data you write to DB_File will go to disk until you untie it, and that can sometimes confuse people. MLDBM::Sync takes care of all that for you. | [reply] |
You could be right. Perhaps there's an interaction with the client that I'm not seeing. The daemon has a watchdog function to close and re-open the databases to flush all updates to the db files (in the event that it crashes, like it has been). I've also managed to get at least one core dump out of my testing, so it may even be a problem in the installed packages.
In the mean time I've written and alternate package to use flat files instead instead of DB_File. Looking at the problem now, I don't know why I didn't do that in the first place. The flat files are easily half (and sometimes much more) as big as the equivalent .db files, and I can open them up in any editor to trouble shoot problems. So far I haven't been able to break the daemon and the client response feels zippier, but that's entirely subjective. I still have the watchdog function scheduled to rewrite the entire file now and again. There's probably a smarter way to update the files without simply writing fresh copies, but it's simple and does the job for now.
| [reply] |
You might look into TIE::File or DBD::CSV at some point, if the amount of code to manage your flat files becomes cumbersome.
| [reply] |