Re: Locking a SQLite DB for tests

The test file will use a fork() whose child will open the db and lock it as above and sleep for some time before disconnecting (thus unlocking it). The parent will try to open the DB and hopefully be able to detect if locked or not.

You're probably aware of that, but it bears repeating for other people that may find this thread that open SQLite connections don't handle fork() well. Kudos for getting it right and only opening the database after the fork()!

Comment on Re: Locking a SQLite DB for tests Select or Download Code

Replies are listed 'Best First'.
Re^2: Locking a SQLite DB for tests by bliako (Abbot) on Jan 28, 2022 at 11:52 UTC
yes, thanks. `fork()` duplicating all handles, will create a mess and on top of that, it will try to close all duplicated handles on exit of child (with commits or rollbacks etc) even if child has not opened any itself! This last will be a hard nut to debug. The only thing it remains foggy, to me, is how testing should go with fork. To start with, test numbers are mixed and Test::More is randomly confused and fails. Using Test::Fork fixes that but with loosing test numbers which takes me to the real problem: I have to ensure a sequence. First the child opens the DB and locks it, next the parent opens the same DB and checks if it's locked and does whatever it has to do on it. That's why I have a `sleep()` just as the parent starts, to give time to child to lock the DB. But that's not guaranteed at all, although chances are miniscule. I believe/read that single SQLite DB is ok being accessed concurrently by many processes. Update: in a sort of rubber-ducking-way, I guess I don't need a fork at all! Just open the DB first and lock it, don't close it. Next (and sequentially), open the same DB and check if it's locked etc. At the end close both connections to the same DB. BTW my test case is to be able to just read the DB when it is locked, nothing fancy more than read. The real situation is Firefox locking aggressively its cookies SQLite db and I can not read the current cookies when FF is running.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Locking a SQLite DB for tests
by bliako (Abbot) on Jan 28, 2022 at 11:52 UTC

yes, thanks. fork() duplicating all handles, will create a mess and on top of that, it will try to close all duplicated handles on exit of child (with commits or rollbacks etc) even if child has not opened any itself! This last will be a hard nut to debug.

The only thing it remains foggy, to me, is how testing should go with fork. To start with, test numbers are mixed and Test::More is randomly confused and fails. Using Test::Fork fixes that but with loosing test numbers which takes me to the real problem: I have to ensure a sequence. First the child opens the DB and locks it, *next* the parent opens the same DB and checks if it's locked and does whatever it has to do on it. That's why I have a sleep() just as the parent starts, to give time to child to lock the DB. But that's not guaranteed at all, although chances are miniscule.

I believe/read that single SQLite DB is ok being accessed concurrently by many processes.

Update: in a sort of rubber-ducking-way, I guess I don't need a fork at all!

Just open the DB first and lock it, don't close it. Next (and sequentially), open the same DB and check if it's locked etc. At the end close both connections to the same DB. BTW my test case is to be able to just read the DB when it is locked, nothing fancy more than read. The real situation is Firefox locking aggressively its cookies SQLite db and I can not read the current cookies when FF is running.

[reply]
[d/l]
[select]