avoid WPF contention-inline problems with transaction

Author: krauthaufen

FSharp.Data.Adaptive.sln

@@ -26,6 +26,14 @@ Project("{F2A71F9B-5D33-465A-A702-920D77279786}") = "Scratch", "src\Demo\Scratch
 EndProject
 Project("{F2A71F9B-5D33-465A-A702-920D77279786}") = "PublishTrimmedTest", "src\Demo\PublishTrimmedTest\PublishTrimmedTest.fsproj", "{11280471-7178-4DC3-9BAD-18411B1AE62B}"
 EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{9C4FEF40-2460-4739-ADC2-AF2FC7F658CE}"
+	ProjectSection(SolutionItems) = preProject
+		paket.dependencies = paket.dependencies
+		paket.lock = paket.lock
+		README.md = README.md
+		RELEASE_NOTES.md = RELEASE_NOTES.md
+	EndProjectSection
+EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		Debug|Any CPU = Debug|Any CPU

RELEASE_NOTES.md

@@ -1,3 +1,6 @@
+### 1.2.16 
+* avoid WPF contention-inline problems with transaction
+
 ### 1.2.15 
 * updated MultiCallbackObject with proper locking https://github.com/fsprojects/FSharp.Data.Adaptive/pull/113
 

src/FSharp.Data.Adaptive/Core/Transaction.fs

@@ -181,7 +181,12 @@ type Transaction() =
                 e.AllInputsProcessed(x)
 
             else
+                // WPF Synchronization-Context inlines code in contending locks.
+                // https://stackoverflow.com/questions/8431221/why-did-entering-a-lock-on-a-ui-thread-trigger-an-onpaint-event
+                // Therefore we treat the "inlined" code as if it were running on a different thread (without a current transaction)
+                Transaction.RunningTransaction <- ValueNone
                 e.EnterWrite()
+                Transaction.RunningTransaction <- ValueSome x
                 try
                     outputCount <- 0