Jens Alfke

Regarding @borrrden 's comment above: > SQLite handles concurrency with locks but that is just to prevent actual corruption and not to address busy and/or race conditions. That isn't relevant...

We have C++-based tests of the C API, but they don't test all the functionality.

I've done this on the `dev` branch in these commits: a7362eea92175130b7c02c14bf46d3c09c9b66c6 ecf9fe1e5f3132d709459c1dee4dddbd68ab42c5 2fd56010039045ac72e3a071d92352e441f86365 43b4dda799c1a7b4ab2f31b55414063cab99f684

ForestDB is calling the compaction callback from the background compactor thread, and unfortunately `Database::compactionCallback` calls `updatePurgeCount()` which isn't thread-safe.

The real fix won't be simple, because the Database class isn't designed to be thread-safe, and CBForest itself has no notion of queues or event loops so it can't somehow...

I already implemented this for c4View on 4/4 in f4d189213e050959e4a3235b85fbd613ca3b64b4. c4view_close will fail with an error if there are enumerators still active.

https://github.com/couchbaselabs/cbforest/pull/84

I just ran into this a few days ago. It's worth looking at what CouchDB does in this situation; it might just ignore the inclusiveEnd flag if there's no endKey.

Good! I had a feeling it would do that, because the alternative is annoying to implement — you have to stay one iteration ahead of what you return, so you...

``` ForestException{domain=2, code=-39} at com.couchbase.cbforest.Database.beginTransaction(Native Method) at com.couchbase.lite.store.ForestDBStore.beginTransaction(ForestDBStore.java:1235) ``` Error -39 means the ForestDB file handle was called reentrantly: ``` c /** * DB handle is being used by another...