-
Notifications
You must be signed in to change notification settings - Fork 33
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
Possible Azure SQL #14
Comments
Haven't worker yet with SqlAzure but is possibile to have on a distributed system this kind of issue. You should handle this "glitch" in your client: I will go for A |
I've messed around a bit, received transaction exceptions in the polling client while using the EnlistInAmbientTransaction() call during the Wireup(). Not sure if it actually solves anything, but gonna try it out for a few days. Regarding opt A and B. Implemented a version of B were we changed ObserveFrom*() to pass UtcNow - 300ms, and ignore all commits newer than that. Giving some time for the infrastructure to catch up. If we settle for opt B, I will eventually send a pull request with a SqlAzureDialect. |
Our issues:
The workaround:
Notes:
|
I believe this to be caused by I wonder if creating an |
I just did a bit of experimentation that showed adding the |
We've created a subclass of MsSqlDialect that adds the What remains is the very low likelihood of #21 occurring, but I think noone has actually ever seen this in production. |
Hi,
We have built a system that is using the PollingClient to feed around 25 commit observing projection builders.
Occupationally in production we have simultaneously received crashes in several of our projection builders at the same time, at the very same commit checkpoint.
When we reset the checkpoint, and feed the projection builders with the entire event stream again, it passes perfectly.
So it appears it sometimes skips a few events!
It only seem to happen during highly intense read+write periods during imports of data.
SQL Azure's default transaction level is different from vanilla MSSQL.
If I write event+0 and event+1 to the database, is it possible that event+1 is available before event+0 in SQL Azure?
In MSSQL we haven't been able to reproduce this result.
Any clues?
The text was updated successfully, but these errors were encountered: