-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locking options #17
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bt default, the kernel uses a global ReaderWriterLockSlim to allow either a single writer or multiple readers at any given time. This is a simple but powerful locking model that guarantees serializable isolation. But a major drawback is that command/query execution time will add to latency and any long running operation will block throughput.
A simple scheme to address this issue would be to used named locks. A given command/query is either associated with a named lock, or will default to the global lock. This will allow more granular locking, bypassing locks and other relaxed locking options.
And if the user has a thread safe model, we should be able to disable locking altogether. So an
ILockingStrategy
interface withNullLockingStrategy
andReaderWriterLockSlimStrategy
implementations looks like a good approach.OrigoDB has an immutability model where the entire model is immutable, and commands return a new model. This might at some point be ported to memstate. However, using locking options as proposed above would allow portions of the model to be immutable. Example:
The huge benefit here is that a query can grab a reference to the Customers list and will get a point in time snapshot without blocking concurrent AddCustomer commands.
The text was updated successfully, but these errors were encountered: