Add System.Transactions to corefx #10089

stephentoub · 2016-07-15T16:10:54Z

This ports System.Transactions from desktop to corefx.

Two main pieces were omitted: COM+/EnterpriseServices integration, and DTC support via OleTx. Those have been stubbed out in helpers that throw PlatformNotSupportedException if used.
All of the Mono tests were ported, as were some of the desktop tests.

There is still more work to be done before this can be considered stable, e.g. adding more tests (in part to help verify behavior remains the same across the port), working through if/how to add built-in distributed transaction support, etc., but this is a good start and should be sufficient to primary use cases around TransactionScope.

cc: @danmosemsft, @jimcarley, @dmetzgar, @SriniBanala, @EricaMo, @DamianEdwards
Fixes https://github.com/dotnet/corefx/issues/2949

stephentoub · 2016-07-18T14:50:49Z

@jimcarley, please let me know if you have any changes you'd like to see made before this is merged, or whether you're ok with this being merged as-is. Thanks!

@ericstj, could you confirm (or deny :) I've done the packaging correctly?

dmetzgar · 2016-07-18T18:55:01Z

src/System.Transactions/ref/System.Transactions.cs

+        public System.Guid PromoterType { get; }
+        public System.Transactions.TransactionInformation TransactionInformation { get { return default(System.Transactions.TransactionInformation); } }
+        public event System.Transactions.TransactionCompletedEventHandler TransactionCompleted { add { } remove { } }
+        //protected System.IAsyncResult BeginCommitInternal(System.AsyncCallback callback) { return default(System.IAsyncResult); }


protected System.IAsyncResult BeginCommitInternal [](start = 10, length = 49)

Is the standard for .NET Core to stick with Task or should we continue to use Begin/End?

Sorry, I should have added a comment here.

Originally for .NET Core, we were exluciding the Begin/End methods in favor of including the Task methods. As part of bringing back lots of APIs, we're bringing back those Begin/End methods that were excluded. I did not remove any such APIs as part of the port.

However, that's not why these are commented out. These are actually part of the Mono APIs, even though they're not in the desktop implementation of System.Transactions. It's unclear to me why such "Internal" methods are exposed as protected in Mono, maybe it's a mistake, or maybe it's there for some corner-case scenario that was desired. In any event, I wasn't sure what to do with them contract-wise, so I left them here but commented out. I'll add a comment explaining.

dmetzgar · 2016-07-18T19:03:25Z

jimcarley · 2016-07-18T21:35:37Z

Stephen,

While I haven’t looked at all of the code, yet, I haven’t seen anything glaring that would prevent this pull request.

I have seen at least one flaw in the ported Mono tests in IntResourceManager.cs and EnlistTest.cs. The return code from Transaction.EnlistPromotableSinglePhase is not really handled correctly. There is no check that EnlistPromotableSinglePhase returns “false” if there is already a PSPE or durable enlistment on the transaction. In the cases where 2 PSPE enlistments are attempted or a Durable followed by a PSPE, there is a check to ensure that there were no enlistment “failures”. This check is based on exceptions being thrown. But a “false” return value from Transaction.EnlistPromotableSinglePhase indicates that the PSPE enlistment could not be created. It isn’t really a “failure”, and thus no exception is thrown. The “false” is an indication that the PSPE enlistment was not possible, but a durable enlistment could be successful and that the caller should attempt such an enlistment.

The above is not necessarily something that needs to be fixed right now. I just wanted to call it out.

Jim

From: Stephen Toub [mailto:[email protected]]
Sent: Monday, July 18, 2016 7:52 AM
To: dotnet/corefx [email protected]
Cc: Jim Carley [email protected]; Mention [email protected]
Subject: Re: [dotnet/corefx] Add System.Transactions to corefx (#10089)

@jimcarleyhttps://github.com/jimcarley, please let me know if you have any changes you'd like to see made before this is merged, or whether you're ok with this being merged as-is. Thanks!

@ericstjhttps://github.com/ericstj, could you confirm I've done the packaging correctly?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//pull/10089#issuecomment-233351735, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMw2-NFXKCMxC_cIO2fvKTXRS1ZTPo1Nks5qW5L5gaJpZM4JNjk8.

jimcarley · 2016-07-18T21:54:21Z

src/System.Transactions/tests/IntResourceManager.cs

+
+                    if (Type == ResourceManagerType.Promotable)
+                    {
+                        _transaction.EnlistPromotableSinglePhase(new PromotableSinglePhaseNotification(this));


EnlistPromotableSinglePhase will not throw an exception if there is already another PSPE or a DurableEnlistment. Instead, it returns false. Right now the tests that exercise these scenarios do not take this into account. This scenario should be taken into account to correctly test EnlistPromotableSinglePhase. One option is to count a "false" return as an enlistment failure.

Ok, so I should basically add an Assert.True around all calls to enlistPromotableSinglePhase that are supposed to succeed? Assuming yes, I'll do that, and if any then cause failures, I'll undo it and add a TODO for follow-up.

No. There are a couple of tests that will induce this to return false, so an Assert.True will break those tests. I think a check for "false" is in order and the "failure" should be counted and verified by the two tests that do this.

In reply to: 71283510 [](ancestors = 71283510)

jimcarley · 2016-07-18T23:20:01Z

// stupid.

Please change this to "Don't allow anything that is not supported."

Refers to: src/System.Transactions/src/System/Transactions/TransactionState.cs:5016 in 0f0da74. [](commit_id = 0f0da74, deletion_comment = False)

jimcarley · 2016-07-19T00:28:21Z

src/System.Transactions/src/System/Transactions/SafeIUnknown.cs

+    // that it will be properly released.
+    internal sealed class SafeIUnknown : SafeHandle
+    {
+        private SafeIUnknown() : base(IntPtr.Zero, true) { }


private [](start = 8, length = 7)

Why did you make this private? In the desktop code, this is internal, just like the other constructor.

Initially I made it private because nothing was using this ctor to instantiate it; the parameterless ctor was only necessary for the P/Invokes that were creating it, and for that purpose private is fine.

But then I subsequently removed all of those P/Invokes, and now nothing is using this type at all, so I'll just remove the file entirely.

stephentoub · 2016-07-19T07:20:35Z

Please change this

Will do.

jimcarley · 2016-07-19T16:21:02Z

src/System.Transactions/src/System/Transactions/Transaction.cs

+            }
+        }
+
+        internal Transaction(DistributedTransaction oleTransaction)


oleTransaction [](start = 52, length = 14)

change the name of this parameter to something like "distributedTransaction"

jimcarley · 2016-07-19T17:15:44Z

This is the vast majority of the implementation, ported to corefx. The main impact is the reliance on OLE has been removed, as has the reliance on COM+. Distributed transactions aren't supported implicitly, but they can be supported via plugging in a non-MSDTC manager via the relevant interfaces.

This ports all of the Mono System.Transactions tests as well as some of the .NET Framework tests. There is plenty more cleanup that can be done; I primarily focused on porting them to xunit.

stephentoub · 2016-07-19T21:48:01Z

Thanks for all the feedback. I've addressed the issues and will merge once the CI build completes.

And fix project.json versions

Add System.Transactions to corefx Commit migrated from dotnet/corefx@af0f5f1

dnfclas added the cla-already-signed label Jul 15, 2016

stephentoub added the 3 - Ready For Review label Jul 15, 2016

stephentoub force-pushed the stx_port branch from 189dfce to 0f0da74 Compare July 15, 2016 19:16

dmetzgar reviewed Jul 18, 2016
View reviewed changes

jimcarley reviewed Jul 18, 2016
View reviewed changes

jimcarley reviewed Jul 19, 2016
View reviewed changes

stephentoub added 3 commits July 19, 2016 14:22

Port System.Transactions tests to corefx

9cd8194

This ports all of the Mono System.Transactions tests as well as some of the .NET Framework tests. There is plenty more cleanup that can be done; I primarily focused on porting them to xunit.

Add packaging for System.Transactions

f7125b3

stephentoub force-pushed the stx_port branch from 0f0da74 to ee09985 Compare July 19, 2016 21:47

stephentoub force-pushed the stx_port branch from ee09985 to bee04b3 Compare July 19, 2016 22:22

Address PR feedback on System.Transactions

d2a27b5

And fix project.json versions

stephentoub force-pushed the stx_port branch from bee04b3 to d2a27b5 Compare July 19, 2016 22:30

stephentoub merged commit af0f5f1 into dotnet:dev/api Jul 19, 2016

stephentoub deleted the stx_port branch July 19, 2016 23:37

stephentoub removed the 3 - Ready For Review label Jul 19, 2016

dagood mentioned this pull request Jul 20, 2016

Remove netcore50 support claim from System.Transactions #10179

Merged

bgrainger mentioned this pull request Jul 29, 2016

Support System.Transactions mysql-net/MySqlConnector#13

Closed

karelz modified the milestone: 1.2.0 Dec 3, 2016

bgrainger mentioned this pull request Apr 15, 2017

Support System.Transactions. mysql-net/MySqlConnector#241

Merged

ngbrown mentioned this pull request Jun 20, 2017

NH-3807 - Support for .NET Core 2.0 nhibernate/nhibernate-core#633

Closed

29 tasks

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022

Merge pull request dotnet/corefx#10089 from stephentoub/stx_port

7bf3d95

Add System.Transactions to corefx Commit migrated from dotnet/corefx@af0f5f1

Add System.Transactions to corefx #10089

Add System.Transactions to corefx #10089

Uh oh!

Conversation

stephentoub commented Jul 15, 2016

Uh oh!

stephentoub commented Jul 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmetzgar Jul 18, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub Jul 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmetzgar commented Jul 18, 2016

Uh oh!

jimcarley commented Jul 18, 2016

Uh oh!

jimcarley Jul 18, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub Jul 19, 2016

Choose a reason for hiding this comment

Uh oh!

jimcarley Jul 19, 2016

Choose a reason for hiding this comment

Uh oh!

jimcarley commented Jul 18, 2016

Uh oh!

jimcarley Jul 19, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub Jul 19, 2016

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Jul 19, 2016

Uh oh!

jimcarley Jul 19, 2016

Choose a reason for hiding this comment

Uh oh!

jimcarley commented Jul 19, 2016

Uh oh!

stephentoub commented Jul 19, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

stephentoub commented Jul 18, 2016 •

edited

Loading

stephentoub Jul 18, 2016 •

edited

Loading