[API Proposal]: add a setter to TransactionManager.DefaultTimeout and MaxTimeout

[wli3]

Background and motivation

.NET SDK's workload install feature uses TransactionScope to control rollback. TransactionScope has a machine level timeout of 10 minutes. And that end up causing long workload installation failure. It impacts all slow internet user for .NET 6.0. Currently a workaround is applied dotnet/sdk#21101

Add #71025, customer is asking to add setter for TransactionManager.DefaultTimeout.

API Proposal

namespace System.Transactions
{
    public static class TransactionManager
    {
        public static TimeSpan DefaultTimeout 
        {
            get; 
+          set;
         } 
        public static TimeSpan MaximumTimeout 
        {
            get; 
+          set;
         } 
    }
}

API Usage

In .NET framework, customer could update these settings in machine.config. However, in .NET Core, there is no way to update these settings anymore.
See issue #1418 and #71025, requested by custeomer.

Risks

Low.

[wli3]

Which release we want to put this in?

[GrabYourPitchforks]

Implementation note: make sure the getter and setter are safe for multithreaded access; the data could be torn on 32-bit archs.

[mconnew]

@GrabYourPitchforks, Interlocked.Read and Interlocked.Write should do the trick I presume? They become no-ops on 64-bit platforms with a simple 64-bit integer, but I don't know if TimeSpan would be treated the same way and be a no-op.

@wli3, would I be correct in saying it's a bit too tight to get this in to .NET 6? They have a workaround for now, so I think .NET 7 would be sufficient.

[mconnew]

Some more thoughts about this, the required value for TransactionManager.MaximumTimeout is mostly affected by the executing environment which is why it was settable via machine.config in NetFx. I think we should also have some non-code way to modify this behavior, e.g. through an AppSetting as I could see a situation where you would want to modify this value for an app in a particular deployed environment and making code changes doesn't seem to be an appropriate remediation when it's not the app that has the problem.

[stephentoub]

They become no-ops on 64-bit platforms with a simple 64-bit integer

On arm, these would still involve fences in the assembly.

(I'm not making any judgements on the rest of the proposal, just clarifying that comment. )

[mconnew]

@stephentoub, can data tearing happen on ARM64 with longs?

[stephentoub]

can data tearing happen on ARM64 with longs?

No (at least not in safe code with things properly aligned... I'm not sure about when things aren't aligned naturally)

[dsplaisted]

Looks like this may be a duplicate of #1418

[bartonjs]

Video

• We would prefer an option without a static setter, like using AppContext to allow the setting to be set (and loaded into a Lazy<T> so it only gets read once)
• As the next fallback, it might be helpful to have the setter only allow set-once (throw on a second call to set)

namespace System.Transactions
{
    public static class TransactionManager
    {
        public static TimeSpan DefaultTimeout 
        {
            get; 
+           set;
         } 
        public static TimeSpan MaximumTimeout 
        {
            get; 
+           set;
         } 
    }
}

[filipnavara]

A similar implementation of AppContext switch for timeout is in the Regex class.

[StephenMolloy]

Fixed by #71703