-
Notifications
You must be signed in to change notification settings - Fork 23
Using ApplicationIntent=ReadOnly in SQL read operations #56
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
base: master
Are you sure you want to change the base?
Conversation
…d server doesn't support 6.0
@@ -39,7 +39,8 @@ public virtual async Task<IAsyncEnumerator<T>> GetEnumeratorAsync(CancellationTo | |||
|
|||
public virtual IAsyncEnumerator<T> GetAsyncEnumerator(CancellationToken cancellationToken) | |||
{ | |||
return GetEnumeratorAsync(cancellationToken).Result; | |||
// TODO: This is a blocking operation in a async context. How may we fix this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation is flawed. The GetEnumeratorAsync
method above should not exist. Instead, this method should prepare all the dependencies and send them to the enumerator. DbDataReaderAsyncEnumerator.MoveNextAsync
implementation will be a state machine; When invoked on its initial state, it will create and OpenAsync
the connection and then ExecuteReaderAsync
. Following invocations would use the current implementation.
This PR introduces a proposal for segregating read and write operations in Elephant's basic storage structures on SQL Server, for enabling the use of secondary replicas for read-only operations.
To allow that, this PR adds three new SQL storages structures:
ApplicationIntentSqlMap
,ApplicationIntentSqlSet
andApplicationIntentSqlSetMap
. Every one of these structures contains a read-only and a write instance of the "real" SQL implementation of the data structure, with the read-only structure receiving an additionalApplicationIntent=ReadOnly
suffix in the connection string. And every method call just forwards the invocation to the adequate instance, according to the method type: queries go to the read-only instance and writes (adding, deleting, updating) go to the writable one.For extending data structures, a new
GetReadOnlyConnectionAsync
base method was added, and it should be used in specific map implementations, like the ones that currently use SQLKata for queries.For testing, an
AuditableDatabaseDrive
decorator was implemented to allow us to assert if the correct connection string was passed for every operation.The idea of adding new structures instead of changing the current ones was to avoid introducing bugs. But this comes with a limitation: in the
ApplicationIntentSqlSetMap
implementation, theISet<T>
value returned by theGetValueOrDefaultAsync
andGetValueOrEmptyAsync
do not segregate the calls by read-only and writable, so implementations that relies on this method will only use writable connections.More information:
SQL Azure: https://docs.microsoft.com/en-us/azure/azure-sql/database/read-scale-out
SQL Server: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-read-only-routing-for-an-availability-group-sql-server