Redmine

Related to #2775?

SQLite will lock the entire file for writing, i.e. during the time it takes for data to be written to disk, nothing else can access the DB ==> no concurrent writes.

I see. This seems to have changed, in the official doc for 1.3 it wasn't discouraged.
It's true that SQLite needs full file locks when writing, however several tests show that the level of concurrency needs to be quite high in order for performance to seriously suffer. For small to medium teams it does perfectly fine (and as I stated, it did with Redmine 1.3).

It's a pity that support was dropped, however I understand such decisions, as every supported option takes resources. Looks like our migration to 2.x gets more expensive then planned...

Dietmar Hofer wrote:

It's a pity that support was dropped

It is not, SQLite is supported, just discouraged.

I don't know how to have it working smoothly with Redmine 2/Rails 3 in a multi-user environment but since it used to work with 1.3 I guess it might be possible?

Etienne Massip wrote:

I don't know how to have it working smoothly with Redmine 2/Rails 3 in a multi-user environment but since it used to work with 1.3 I guess it might be possible?

I also think it's possible. According to http://stackoverflow.com/questions/78801/sqlite3busyexception the way to deal with sqlite locks is to shortly wait and retry. I don't know if that was the case in 1.3, but since we didn't have the issue in a year running 1.3 with the same concurrency, I imagine something was different.

See Moving from sqlite to mysql: plugin migration fails for how to migrate.

The errors above are not actually concurrency issues with SQLite3. They are bugs in the way SQLite3 is used.

The original bug posted also indicates an error in the way the adapter is handling concurrent access. Subsequent "database is locked" messages are explained here:
http://www.sqlite.org/cvstrac/wiki?p=DatabaseIsLocked

The gist is that something really bad happened in terms of using the given connection and it is most certainly an issue in the use of the database (most likely in the adapter layer).

A concurrency error looks exactly like the second one posted on the bug -- the database is locked by a process (you can typically find out which one, at least on Linux, by looking in /proc/locks and looking up the PID for the lock holding the DB open). But I strongly suspect this is an actual bug.

SQLite3 adapter in Rails 3.2.xx has the following bug as well: https://github.com/rails/rails/issues/13595

Most likely, the problem in this bug is a result of https://github.com/rails/rails/issues/13631 (again, a bug in the ActiveRecord SQLite3 adapter, which is still present in Rails 4).