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

Support Async Transaction APIs #9015

Closed
caleblloyd opened this issue Jun 29, 2017 · 3 comments · Fixed by #16426
Closed

Support Async Transaction APIs #9015

caleblloyd opened this issue Jun 29, 2017 · 3 comments · Fixed by #16426
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone

Comments

@caleblloyd
Copy link

@divega opened this to CoreFX a while ago: https://github.com/dotnet/corefx/issues/10975 but it doesn't look like there has been any movement.

Our ADO.NET provider, MySqlConnector has BeginTransactionAsync, CommitAsync, and RollbackAsync

We like to use them in Pomelo.EntityFrameworkCore.MySql to avoid running Sync-Over-Async I/O and cut down on thread pool lockups.

EF does not lend itself well to supporting these Async methods. We have to override every single method that begins, commits, or rolls back a transaction in our provider.

I think that EF should add a class that allows for the provider to define whether or not it supports Async transaction APIs, and use those instead of the Sync ones if it does.

@divega
Copy link
Contributor

divega commented Jun 29, 2017

Thanks @caleblloyd for the information. I think we agree that the long term solution would be for the base ADO.NET classes to add these capabilities. Can you please make a comment in dotnet/corefx#10975 detailing what your MySQL provider could use?

Maybe there is something we can do on EF Core in the shorter term. We will discuss it in triage.

@caleblloyd
Copy link
Author

If #9014 gets fixed, then more transaction related code is going to get into EFCore.Relational and I think that it's important to allow providers to use Async transaction codepaths.

I opened a PR in #9017 with my idea about what this would look like as a solution for just EF. Basically we move the async APIs that we want ADO.NET DbConnection and DbTransaction to their EFCore.Relational counterparts and make them virtual so the provider can override with a real async implementation.

@divega
Copy link
Contributor

divega commented Jul 2, 2019

@ajcvickers, I think you are about to fix this, so assigning to 3.0.

ajcvickers added a commit that referenced this issue Jul 3, 2019
@ajcvickers ajcvickers added closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. and removed blocked labels Jul 3, 2019
ajcvickers added a commit that referenced this issue Jul 3, 2019
@ajcvickers ajcvickers modified the milestones: 3.0.0, 3.0.0-preview8 Jul 29, 2019
@ajcvickers ajcvickers modified the milestones: 3.0.0-preview8, 3.0.0 Nov 11, 2019
@ajcvickers ajcvickers removed their assignment Sep 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants