-
Notifications
You must be signed in to change notification settings - Fork 32
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
Optimistic concurrency control by NES and NeventStore+SQL #42
Comments
@lees-oz using (var stream = _eventStore.OpenStream(bucketId, id, version, int.MaxValue)) The version here says, which the minimum version of the stream should be. So when you attend to open version 2, maybe the opened stream version will be 3, but you expected to be 2, because you made your business decisions based on the state of the version 2. Therefore is the check there. Do you agree? |
Not completely, because between the moment you do the check and the moment you persist stream there's a possibility that version 3 will be added by concurrent thread. So that check cannot guarantee the event stream consistency in the storage. In case of SQL storage, SQL only can guarantee that (with PK mechanism). Then I get that exception:
If this check in NES detects the concurrency conflict, I get same exception type, with a different message and stacktrace though:
Those 2 exceptions mean same and it's not clear for me why distinguish them, especially if that costs another |
You are right. Let's check some examples: Example 1: This is totally fine, our additional check not needed. Example 2: Here we have no database exception, because we have no conflict. In second example we made our business decision based on stream 2 and not stream 3, therefore the check. Do you agree now? |
Probably I know where the confusion comes from. You have to open the stream(s) second time, when you Commit unit of work. Because if you use the one you've opened before "job is done", and write it with incremented version, db exception should do the trick. Am I correct? |
Correct. If NES would keep the stream opened during the whole UnitOfWork, then we would get the db exception like expected by you previously. Actually during the read NES opens and closes the stream. Then, when NES is going to write, it opens the stream again and then it writes and closes the stream. |
Clear, and what is the reason of not keeping it open? What kind of trade-off is it? |
Did not analyze what consequences this would have. What are the drawbacks of the actual solution etc. Any suggestions and pull requests are welcome. |
Hi there,
I've noticed that when the stream is commited, NES performs a read first to detect concurrency:
Still there's a possibility for concurrency issue this way (result of
OpenStream
becomes stale immediately). I am using NEventStore with SQL persistence and the consistency of event stream is guaranteed by the database (PK on bucket, streamId and version). So theOpenStream
looks like a redundant action in that case for me.Please comment on that, thank you!
The text was updated successfully, but these errors were encountered: