> On Sep 8, 2014, at 2:26 PM, Mark W. <[email protected]> wrote: > > I created a serial queue and wrote everything to take advantage of it. > Unfortunately, this doesn't force the internal features to use this queue. > For instance, I was using CBLModel's autosave feature - that always triggers > on a separate thread. CBLLiveQuery's indexing is done on a separate thread > too.
Sorry you're having trouble with threads contending over the database; it's frustrating, I know. Autosave happens on the database's thread/queue except in the case where all models are autosaved when the app goes to the background; there was a bug (#441) that caused this to happen on the main thread. I fixed that last week after it was reported, and the patch is very small and easy to cherry-pick if you need it. Indexing and replication always happen on a background thread, though. > When under load, these background threads don't serialize access to the > database and start throwing database busy errors. Database access is serialized through file locks by SQLite. The problem is that SQLite polls the lock, i.e. keeps trying to open the database until a timeout. This doesn't work well when the database is under heavy load by a different thread, it turns out. The real fix for this will be replacing SQLite with ForestDB, which doesn't have any of these issues. This will be part of the next major release of CBL. > Looking at the code, there does not currently appear to be a way to trap or > report on those errors - they just go to NSLog. I don't believe so. They'll be reported through the API. The SQLite call will fail with error SQLITE_BUSY, and the CBL code will pass that up the call chain and wrap it in an NSError at some point. > The load I was working with was just over 1 new document/model per second. > This is on an older MacBook Pro with a spinning drive. That in itself is a tiny load, but by spacing documents out that way you're creating a lot of transaction overhead. A single SQLite transaction takes a lot of time (on the order of 100ms, I think) flushing data to the filesystem to ensure durability. If you're creating or updating a lot of documents, it's much better to collect them together and save them in one transaction. You also end up triggering the LiveQueries and re-indexing your views after every individual insertion, which adds more overhead too. > 1. Better handling of "Database busy" errors - even if it just throws a > NSNotification so the app can be aware. Again, as far as I know they are handled. If you know specific cases where they aren't, please file issues. > 2. If dispatchQueue is set, run "automated tasks" in that queue. No, the indexing and replication tasks are intentionally run on a background thread to avoid blocking the thread/queue you're using. > 3. Some version of validation test for view indices. I'm not sure what you mean by this? —Jens -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/AE1BDF2A-B63A-4BAC-8AA3-BD82EE8A0289%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
