On Wed, Apr 13, 2011 at 9:05 AM, Mark Hamburg <m...@grubmah.com> wrote:
> I have a database for which I essentially want to support three streams of 
> operations: writing, reading fast queries (e.g., lookup a single record), and 
> reading complex queries (e.g., find all of the records matching a particular 
> criterion). I would like to have these run with as little interference as 
> possible between them. I'm on iOS, so I can't use processes (just to avoid 
> the whole "don't use threads, use processes!" spiel). That last point, 
> however, leads to the issue that the SQLite documentation says very little 
> about threading other than "SQLite is threadsafe, don't use threads." So, I 
> wanted to see whether I have the right checklist in mind for implementing 
> this:
Mozilla does something similar with it's places.sqlite database.

> 1. Use WAL mode so that the reads and the writes can proceed essentially in 
> parallel. (Reads can interfere with checkpoints but assuming the system 
> quiesces often and checkpoints then, that shouldn't be an extended problem.)
Yes, you want to do this.

> 2. Use one thread (or on iOS probably one GCD dispatch queue) per stream of 
> work.
And this.

> 3. Open a connection per thread?
Yes.

> 4. Shared cache? Yes or no?
You do not want to do this.  Doing so will make all your connections
have the same cache which sounds good right up until you find out that
it means all access to the cache is serialized between all the
connections.

Hope this helps!

Cheers,

Shawn
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to