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

Implement distributed/promoted transactions in System.Transactions. #19318

Closed
jimcarley opened this issue Nov 9, 2016 · 17 comments
Closed

Implement distributed/promoted transactions in System.Transactions. #19318

jimcarley opened this issue Nov 9, 2016 · 17 comments
Assignees
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Transactions
Milestone

Comments

@jimcarley
Copy link
Member

Issue moved to dotnet/runtime #14099

@jimcarley jimcarley self-assigned this Nov 9, 2016
@karelz karelz changed the title Future: Implement distributed/promoted transactions in System.Transactions. Implement distributed/promoted transactions in System.Transactions. Nov 10, 2016
@XieJJ99
Copy link

XieJJ99 commented Jun 11, 2019

@ajcvickers @stephentoub The SQL Server team had already provided MSDTC for SQL Server on Linux. Is there any plan to promote the MSDTC for linux as a generic service so that it's possible to support distributed transaction on Linux?

@ULSTechology
Copy link

ULSTechology commented Jun 26, 2019

A lack of support for distributed transactions is pretty disastrous for anyone wanting to migrate their old system onto .NET Core.

This puts an end to our hopes that we can start using Blazor - we can't rewrite our entire application to work without distributed transactions, there's just too much of it.

@popcatalin81
Copy link

we can't rewrite our entire application to work without transactions, there's just too much of it.

Surely, if you can rewrite for Blazor, which is a significant rewrite anyway, you can also eliminate distributed transactions.

@ULSTechology
Copy link

ULSTechology commented Jun 26, 2019

we can't rewrite our entire application to work without transactions, there's just too much of it.

Surely, if you can rewrite for Blazor, which is a significant rewrite anyway, you can also eliminate distributed transactions.

Using Blazor requires a rewrite of the UI, and we can start small with that.

Rewriting some fairly large chunks of our data access layer, and probably even some of our business layer, is a whole other matter. Unfortunately, it's not an option we could consider at the moment.

@mmaderic
Copy link

mmaderic commented Jul 15, 2019

I would like to vote up for this feature at least for databases on single SQL server instance.

I have case where I would like to enclose two different database commits into single system transaction. (Sort of micro-service architecture).

@abbotware
Copy link

@LaterStart - I have the same use case so +1

Creating multiple exe microservices (service fabric) sharing a single SQL database (migration of legacy code / data)

I found it is possible on Net Core to share transactions/connections between ADO. and EF Core within a single process (https://docs.microsoft.com/en-us/ef/core/saving/transactions) ,

However, what options currently exist when 2 separate Net Core exes are involved for implementing a 2 phase-commit like pattern?

  1. Can the DTC / Resource Manager be simulated via base classes in Net Standard? (https://docs.microsoft.com/en-us/previous-versions/ms229975(v=vs.90))

  2. Call the DTC directly via Win32 Api and some how enlist?

1-2 seem like a lot of work, but from what I have read (somewhere) I could just target Net Standard 2.0 and run within a Net Framework host - That will allow System.Transactions to enlist / promote into a DTC transaction, (I can settle for Netstandard + 4.7.2 + new sdk project format if that is my only option)

Even if I use a Net Framework Host (or Net Core if this open issue ever gets implemented), does that mean it should it is possible to obtain the transaction token / correlation id from process A so it can be sent/serialized to process B for manual enlistment?

@pappasa
Copy link

pappasa commented Sep 3, 2019

How do you use .NET Core with IBM WebSphere MQ queue? For example, I do not want to remove the message from the queue, and the put to the database to fail.

@aajmot
Copy link

aajmot commented Sep 20, 2019

can someone tell me if the issue has been fix or still there?
It's almost 2020 now?
Is there any other way around, please tell me.

@pi3k14
Copy link

pi3k14 commented Oct 11, 2019

@dasetser
wtf - you moved this into the unforeseeable future?
Don't you want to on-board enterprise solutions to .Net Core, you want to push us all over to the dark side (java)?

@am11
Copy link
Member

am11 commented Oct 11, 2019

Going by https://referencesource.microsoft.com/#System.Transactions/System/Transactions/Oletx/DTCTransactionManager.cs,2c1154236b6b7acf, seems like there are some win32 specific components involved which probably is the main hurdle. Could someone shed light on what are those and what would require to bring them cross platform?

@dasetser
Copy link

This got moved to future because after investigating it we determined it's going to be a significant rewrite of the feature rather than just a port. We're looking into options for this, but we aren't able to commit to getting this done in the upcoming release.

The main hurdle is that System.Transactions depends on MSDTC when it has to promote transactions, but MSDTC is only available on Windows. In order to get this to work cross platform we would need to rewrite the feature to allow it to work with other distributed transaction coordinators that are available on other platforms, or look into doing something similar to what the SQL Server team did where they brought the DTC components inside the SQL component. Either approach would be a significant change to this feature.

@Peperud
Copy link

Peperud commented Oct 15, 2019

Where do I vote for this?

@pi3k14
Copy link

pi3k14 commented Oct 16, 2019

@dasetser - I appreciate your clarification.
But, us current users of Distributed transactions don't care about cross platform.
Just support it on Windows, and put this cross platform paradigm that we haven't request into the future.

Thank you.

@am11
Copy link
Member

am11 commented Oct 16, 2019

Thanks for the explanation @dasetser.
If the target linux machine has MSDTC component from SQL Server installed, and its C API is the same as Windows, can the implementation take advantage -- as in, SQL Server as a prerequisite (for now)? We can separately request and poll SQL Server team to ship MSDTC component as a standalone library. :)

@randyburden
Copy link

We were planning to begin porting many of our current applications to .NET Core starting next week as well as start writing our new apps on .NET Core but we just ran into this issue of distributed transactions not working which feels like a deal breaker. Almost every application we write or will write in the future requires distributed transactions.

It is very odd to have experienced a platform not supported exception with this particular feature when we all know that it already exists in the full .NET Framework. It's hard to understand why a Windows platform specific implementation wasn't implemented either in CoreFX or as a shim NuGet package.

Is there a workaround?

@pi3k14
Copy link

pi3k14 commented Dec 6, 2019

@dasetser - Wouldn't implementing WS-AtomicTransaction be the way to go. And since MSDTC supports it and WCF has an implementation of it https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/using-ws-atomictransaction this shouldn't take that much time. Those wanting distributed transactions on Unix can then get a third party solution.

@StephenBonikowsky
Copy link
Member

Issue moved to dotnet/runtime dotnet/runtime#14099 via ZenHub

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Transactions
Projects
None yet
Development

No branches or pull requests