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

Allow providers to override ambient transaction access #24209

Merged
1 commit merged into from
Feb 25, 2021

Conversation

roji
Copy link
Member

@roji roji commented Feb 21, 2021

Accessing Transaction.Current (in HandleAmbientTransactions) is a heavy operation - profiling shows it to take around 0.3% of the total running time.

Npgsql has connection string parameter to disable this check at the ADO level. Allowing providers to override HandleAmbientTransactions would allow EFCore.PG to skip this if the parameter is set.

HandleAmbientTransactions isn't a great name for a publicly-exposed method, but I don't really have anything better...

Related Npgsql PRs: npgsql/efcore.pg#1742, npgsql/npgsql#3570

Copy link
Member

@AndriySvyryd AndriySvyryd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to just wrap Transaction.Current and expose it on ITransactionEnlistmentManager, this way all places using it would benefit.

@roji roji changed the title Allow providers to override HandleAmbientTransactions Allow providers to override ambient transaction access Feb 25, 2021
@roji
Copy link
Member Author

roji commented Feb 25, 2021

Good point for doing it for other places (e.g. BatchExecutor).

Though the intent here was to also allow skipping the _ambientTransactions checks that come after (Count, TryPeek), i.e. to skip HandleAmbientTransactions altogether (even if perf-wise it's probably not very significant). Should we do both? Am OK to also only do Transaction.Current.

&& Transaction.Current == null
&& CurrentContext.Context.Database.AutoTransactionsEnabled)
&& transactionEnlistManager?.EnlistedTransaction is null
&& transactionEnlistManager?.CurrentAmbientTransaction is null
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note slight behavior change where the connection doesn't implement ITransactionEnlistmentManager but Transaction.Current is non-null. New behavior seems more correct.

@AndriySvyryd
Copy link
Member

Though the intent here was to also allow skipping the _ambientTransactions checks that come after (Count, TryPeek), i.e. to skip HandleAmbientTransactions altogether (even if perf-wise it's probably not very significant). Should we do both? Am OK to also only do Transaction.Current.

If we expose HandleAmbientTransactions then we would also need to expose _ambientTransactions in some way in case the provider wants to do something else than skipping. I'd prefer to defer this for now until there's a another use case for this.

@roji roji force-pushed the AllowSkippingAmbientTransaction branch from 390e5cb to bb2df4c Compare February 25, 2021 15:41
@roji
Copy link
Member Author

roji commented Feb 25, 2021

Makes sense, changed HandleAmbientTransactions back to private.

@ghost
Copy link

ghost commented Feb 25, 2021

Hello @roji!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost
Copy link

ghost commented Feb 25, 2021

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

  1. Azure Pipelines

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Give feedback on this
From the bot dev team

We've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments.

Please reach out to us at fabricbotservices@microsoft.com to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants