On 4 Nov 2015, at 8:00am, ALBERT Aur?lien <aurelien.albert at alyotech.fr> wrote:
> - this thread uses a transaction : BEGIN at import start, COMMIT/ROLLBACK at > import end > - during the import (which is very long to execute, sometimes several hours), > another thread execute reads on the same database (different connection) > because of user actions on the main GUI If this thread can generate a lot of commands then they all have to be committed when you do COMMIT. This can last a long time and during that time other threads will be unable to access the database. I believe SQLite should be issuing SQLITE_BUSY or SQLITE_LOCKED if the timeout fails but it's possible something is going wrong. It is especially likely that something is going wrong if your database is held remotely. For instance, on a disk mounted over the network using SMB or CIFS rather than a disk inside the computer running all your threads. > - or commit the import transaction periodically, maybe every "n" seconds or > every "n" imported data This is a common solution: commit either every "n" seconds (best if there can be user delays) or every "n" commands. Another is that instead of issuing your commands to the database you store them somewhere ... a text file or an array of strings ... and then execute them all, inside one transaction, when it's time to COMMIT. Which one of the above you use should depend on what you prefer to happen if the system crashes while writes are pending: do some of them or forget them all. Simon.