http://qs1969.pair.com?node_id=1081257


in reply to 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.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
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.