I was prototyping a gui using a SQLite-backed Rails (on Windows). I
wrote
a seperate Ruby script to populate an events table with filler data.
As part of some
discussion I got it into my head to just fill up the table and see what
kind
of performance issues, metrics or database size issues I would be
exposed
to. The script was executed from the command line (i.e. 2 different
processes)
The script made Rails unresponsive for a start (just getting stack
traces
when it tried to hit the DB), and eventually the script itself bombed
out.
“SQLite::Exceptions::SQLException: unable to open database file”
Admittedly this script was a quick and dirty job with a 100.times
do…end
loop around it, but I expected SQLite to handle contention better than
that.
Multiple processes accessing the database is going to be a core aspect
of a new project we are doing, and I was wondering if this is beyond
SQLite’s capability, or if it can be configured in a way to have more
flexible contention.
I am curious if this is a problem with non-client server databases in
general. It strikes me that to control this kind of contention you need
some code between your calling application and your database engine,
or the DB adapter code in each process has to be a fair bit smarter
than it needs to be.
(I resent this post. Apologies if anyone got it twice)