> Isolation in SQLite is SERIALIZABLE. Note that SERIALIZABLE > implies that locking can be no more fine-grained than table-level. > You can obtain table-level locking in SQLite now. Just put each > table in a separate database file and ATTACH as many tables to > your connection as you require. Yes, I did think of that, but it's a bit messy and things like relationships no longer work. I have a question on that also, would attaching databases make queries quite a bit slower? Does SQLite maintain a cache of connections for each of these 'ATTACH'es, or on each query, does it have to make a connection and retrieve info then close it again? That would be quite an overhead would it not?
> Beginning with version 3.3.0, you will be able to configure SQLite > so that multiple connections running in the same thread will be > able to select READ UNCOMMITED isolation relative to one another. This sounds really interesting, I think it would help some of our tasks but we do have multiple threads accessing the database abstraction layer so those areas wouldn't be able to use this which is a shame ... I would interested if improvements in concurrency is an ongoing thing with more and more support being added as versions get released? Maybe we could assist development in that area possibly if required, but as it may be a core area you would rather control this part of development yourself. What are your thoughts? Thanks for your answers and I must say thanks a lot for your hard work in the development in SQLite ... I have done *a lot* of investigation in databases for my testing and there is a lot of *rubbish* out there, there is a lot of *expensive* solutions, and a lot of *slow* solutions, SQLite is by far one of the quickest, easiest to use and integrate, excellently documented with good user support (through these lists), small/light, and its *free*!! Well done and Merry Christmas to you.
