Hi,
I'm observing the database with a TransactionObserver. I store incoming events in an array for later processing. Since the documentation mentions:
Note : all callbacks are called in a protected dispatch queue, and serialized with all database updates.
I wonder whether the didChange callback is the proper place to do (lengthy) read requests and related calculations. Or will this block (write and other read) accesses to the database.
I think I just need a db.read {} block, but I'm not sure that's what the documentation is telling me.
Thanks in advance.
Kind regards,
Remco Poelstra
Ah, I already found the solution:
Transaction Observers can also use concurrentRead in their databaseDidCommit method in order to process database changes without blocking other threads that want to write into the database.
Yes!
concurrentRead (and its async sibling asyncConcurrentRead) are very useful APIs that allow to release the writer dispatch queue of a database pool, and yet perform a read from a known database state (the one at the point those methods are called). Calling them from databaseDidCommit is such a state.
This is how ValueObservation uses concurrentRead from databaseDidCommit. It fetches fresh and accurate values, (1) without blocking the writer as said above, and (2) with the guarantee that the fresh fetched values are notified in the same order as the impactful database transactions. I haven't tried to preserve this ordering guarantee with asyncConcurrentRead: this is left as an exercise for the interested reader.