Skip to content

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

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

andrebires
Copy link
Contributor

@andrebires andrebires commented Jan 18, 2022

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 and ApplicationIntentSqlSetMap. 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 additional ApplicationIntent=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, the ISet<T> value returned by the GetValueOrDefaultAsync and GetValueOrEmptyAsync 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

@andrebires andrebires marked this pull request as ready for review January 18, 2022 17:00
@andrebires andrebires changed the title Using ApplicationIntent=ReadOnly on SQL read operations Using ApplicationIntent=ReadOnly in SQL read operations Jan 18, 2022
@@ -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?
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants