Skip to content
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

Open
rofr opened this issue Sep 7, 2017 · 0 comments
Open

Locking options #17

rofr opened this issue Sep 7, 2017 · 0 comments

Comments

@rofr
Copy link
Member

rofr commented Sep 7, 2017

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 with NullLockingStrategy and ReaderWriterLockSlimStrategy 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:

public class MyModel
{
   ImmutableList<Customer> Customers {get;set;}
}

public class AddCustomer : Command<MyModel>
{
   public Customer Customer{get;set;}

   public void Execute(MyModel model)
   {
      model.Customers = model.Customers.Add(Customer);
   }
}

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.

@rofr rofr added this to Todo in Memstate 1.0 Nov 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Memstate 1.0
  
Todo
Development

No branches or pull requests

1 participant