search

dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
9.99k stars 2.02k forks source link

Distributed OpenXA Transactions #7017

Closed chris0x42 closed 7 months ago

chris0x42 commented 3 years ago

In my current project we are looking at Orleans because we want to scale the backend and also support linux with .NET 5 but on the other side we have to have distributed SQL transactions. Currently we are heavily relying on MSDTC with full .NET framework for distributed SQL transactions. We want to avoid Sagas because the transactions aren't long running and we don't want to create the 'undo'-actions ourselves.

We are now searching for a way to use the distributed transaction system in Orleans to support our scenario. Is it a good idea and a valid approach to write a custom MSSQL/Oracle/etc. transactional state storage that can map a (global) Orleans transaction to a (local) SQL database transaction using the proprietary OpenXA interfaces provided by each SQL database server?

The Load method starts (or restores) the XA database transaction while the Store method prepares, commits or rollbacks the XA transaction according to statesToPrepare, commitUpTo and abortAfter. The Store method also saves the Orleans transaction metadata to the MSSQL/Oracle database in a custom format to allow restoring the Orleans transaction later again. The grain implementation ensures that one transactional state storage has only one state version for each Orleans transaction because locking the transactional object on the Orleans side (ReadWriterLock) is not required in this case. The grain reads its transactional state to retrieve a new/restored XA transaction cookie. This cookie can now be used when opening new SQL connections to enlist in the coordinated SQL transaction. The grain must invoke state.PerformUpdate() when updating state on the database to indicate that the transactional state must be stored as well (commit or rollback).

We already implemented a PoC that showed that this approach works fine for two different MSSQL servers (without persisting the metadata yet). Before making the implementation reliable and going to production we want to ask here for more opinions/feedback/other ideas about this mapping concept.

ReubenBond commented 3 years ago

Is it a good idea and a valid approach to write a custom MSSQL/Oracle/etc. transactional state storage that can map a (global) Orleans transaction to a (local) SQL database transaction using the proprietary OpenXA interfaces provided by each SQL database server?

It may work, though I think it's very likely that you'll find that Orleans Transactions don't map well to OpenXA, especially in abort/recovery scenarios. It might be better to avoid Orleans' transaction processing system here and create something purpose-built. If you can identify the transaction using RequestContext properties, then you could flow those along the call chain and let each participant flow that information to the OpenXA-compatible/MSDTC databases.

Apologies for the very slow response.

ghost commented 2 years ago

We've moved this issue to the Backlog. This means that it is not going to be worked on for the coming release. We review items in the backlog at the end of each milestone/release and depending on the team's priority we may reconsider this issue for the following milestone.