github/Akavache — pull request #65 by niik (2013-08-23 01:49:29+00:00)
Title: Reinstate SQLite connection serialization 

This PR reverts commit dd54e49d6a6cac73631efb9b17f4e2e07c63bd34.

With dd54e49d6a6cac73631efb9b17f4e2e07c63bd34 in place all reads and writes to a particular database are using a shared SQLite connection (since the connection pool only pools by connection string). That's a bit scary since SQLite connections [are not thread safe](http://www.devart.com/dotconnect/sqlite/docs/Devart.Data.SQLite~Devart.Data.SQLite.SQLiteConnection.html)

> Note that SQLiteConnection instance is not guaranteed to be thread safe. You should avoid using the same SQLiteConnection in several threads at the same time. It is recommended to open a new connection per thread and to close it when the work is done.

In our case this lead to data "corruption" on certain write bursts. We'd have multiple threads trying to write CacheElements simultaneously and sometimes we'd end up with the Key from one write and the Value from another. We never experienced _actual_ corruption of data leading me to suspect that what's actually being contended is the [PreparedSqlLiteInsertCommand](https://github.com/github/Akavache/blob/804fe6b4984fe45607348e0a20a74a0d031ba81e/Akavache.Sqlite3/SQLite.cs#L1307) which is stored per connection and not the actual low-level connection.

There's probably a better way of enforcing per thread serialization (perhaps by implementing more clever connection pooling) but reverting this commit _should_ be an adequate workaround for now.

A backport for 2.x is available in [akavache2-serialized-access](https://github.com/github/Akavache/tree/akavache2-serialized-access).