Single-writer/Multi-reader Classes: Object Transaction and Read Only Database Pool #327
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey there -
I wanted to offer up some FMDB extension classes that my team has been relying on internally to develop LayerKit. Our framework has two main pieces: a sync engine that is running constantly and a public API that performs database queries and mutations to drive synchronization activities. Because of the amount of concurrency on-going at any given time, we have opted to implement single writer / multi-reader on top of FMDB. These classes provide a few things:
FMDatabaseTransaction
class provides an object interface for mediating concurrent access to a single writable connection. It uses a semaphore to ensure that only one object can acquire write access to the database at any time. This is a more convenient interface for us than blocks in some cases because of how write access flows through the sync system.FMReadOnlyDatabasePool
class provides an interface for mediating access to a finite pool of readers. Under the hood a hash map table of proxy objects guarantees that connections return to the pool as objects are reaped by ARC.There’s some obvious overlap with the
FMDatabaseQueue
implementation, but this API is tailored to the reader use-case and the automatic management of connections returning to the pool is very convenient in practice. Anyway, we thought we’d share and see if there’s interest. Happy to make any adjustments necessary. I also have some test cases for the classes, but they are dependent on Expecta so I didn’t pull them in yet.