Re: Unexpected and uncatchable database corruption errors using DBD::SQLite & Parallel::ForkManager

You should check the SQLite docs about whether that library supports multiple simultaneous connections to the same database file. I just found this very nice summary about applications that should and should not use SQLite.

The sections there about client/server applications and high concurrency lead me to think that SQLite and multi-threading are not a good combination. The latter section specifically says SQLite "will only allow one writer at any instant in time."

Update: the bottom line is: either you have to complicate your own script in order to overcome SQLite's limitations (choroba's reply below suggests there's already a CPAN module to help with that), or else you have to pick a more capable type of database.

Comment on Re: Unexpected and uncatchable database corruption errors using DBD::SQLite & Parallel::ForkManager

Replies are listed 'Best First'.
Re^2: Unexpected and uncatchable database corruption errors using DBD::SQLite & Parallel::ForkManager by choroba (Cardinal) on Apr 05, 2014 at 15:56 UTC
That's why I had to use DB_Repeat. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply]
Re^3: Unexpected and uncatchable database corruption errors using DBD::SQLite & Parallel::ForkManager by djerius (Beadle) on Apr 06, 2014 at 19:41 UTC
Thanks; I've been using Try::Tiny::Retry which is similar.	[reply]
Re^2: Unexpected and uncatchable database corruption errors using DBD::SQLite & Parallel::ForkManager by djerius (Beadle) on Apr 06, 2014 at 19:19 UTC
The SQLite documentation indicates that it can handle multiple simultaneous read connections. It only allows one writer at a time, locking the database during the write. If it cannot lock the database, it returns a "database is locked" error. I'm testing this on a local disk (no NFS shenanigans involved), so the locking mechanism should work.	[reply]