Can multiple applications access a SQLite database?

Question

I get into some database lock (SQLite_BUSY) troubles and I fear that SQLite will not work for me.

Basically, my setup is a cronjob which periodically calls some unspectacular Java functionality and (just new in the project) an Jetty/Jackson/Hibernate REST service via a framework called Dropwizard. Both 'modules' need to have database access - and that maybe to the same time...

So, can multiple applications access a SQLite database, or do I need to switch to MySQL?

Answer 1

SQLite can handle multiple applications reading the db at the same time, but not writing to it.

From the SQLite FAQ:

Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.

Answer 2

So, can multiple applications access a SQLite database,

Yes, they can!

From the same FAQ that linked in the user2062950 answer: "When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business.".

In order to avoid the SQLITE_BUSY error you should specify how much a process should wait for the lock. You can do this with the busy_timeout pragma, using it from every process, setting it once after the database is opened.

PRAGMA busy_timeout = 100;

Note that in the WAL mode writing to the database doesn't block the readers, which is awesome, but the writers still need to synchronize between themselves and will do this automatically if you set the busy_timeout for them.

P.S. While the busy_timeout is the prepackaged way to implement concurrent SQLite locks, my advise would be to implement the spinning manually instead, in order to achieve more control and reliability.

There are instances when with SQLITE_BUSY the database is waiting too much.

And blocking locks are a bad idea anyway. Implementing a spinning lock manually in turn allows for deadlock detections, timeouts, locking dashboards.