Support Transactions in .NET Core

[cskardon]

See comment #135 (comment)
Waiting for .NET Core to be 1.1 1.2 when DTC will hopefully be implemented.
(see https://github.com/dotnet/corefx/issues/2949)

[raskolnikoov]

Is it covered yet?

[cskardon]

No - they've moved to 1.2 (https://github.com/dotnet/corefx/issues/2949)

[jedielson]

I Think in 2.0.0 preview version it's already avaliable

[cskardon]

I believe you're right - but after the pain of the last 'preview' I really don't want to go there until it's released :/

[italopessoa]

Hey, 2.0.0 is already released. Any news about supporting transactions?

[ghost]

Hi! Now 2.1. is already released, any progress on transactions support?

[rliberoff]

Hello!

Do you have any news on when could we expect a new version supporting transactions when using .NET Core 2.0?

We really need this.

Thank you.

[cskardon]

No, there is no news, feel free to try to pull request this - time wise I will struggle at the moment.

[CodySchrank]

What needs to be done to add transaction support to this? Net core 2.1 added transactions so is this possible now?

[felipecalvo]

Hey! Would really like to have transaction support in this. What can we do to help?

[cskardon]

Hey all,

Whilst it's true that TransactionScope does exist in Core 2.1 - unfortunately this isn't the only class that needs to be in to do it. Largely I think the best approach is going to be to rewrite the Tx support for core in a separate 'non-transactionscope' way and then port that to the full version later.

It's on my list, but as with all things - work etc time is of the essence. I would stick to the same transaction interface that the scope version uses, but not use the scope.

Probably would make sense to go for Core/Bolt first, then we'd be in a good place.

I apologise this isn't a) done yet b) had much progress at all... life.

[misiek1984]

@cskardon ,

We'd like to use Neo4jclient in our .NET Core project but support for transactions is a must-have for us. I saw this attempt (#318) to do that. It seems to work but the implementation is not perfect, specifically, it lacks unit tests so I cannot trust it fully.

Looking at your comments:

1. "I think the best approach is going to be to rewrite the Tx support for core in a separate 'non-transactionscope' way"
2. "I have a structure in mind that would allow me to join the Tx stuff into Core and Full, with 'extra' packages to add the TransactionScope stuff"

I understand that you have some idea in your head but you don't have time to do it. I think that we can potentially invest time in implementing .NET Core transactions in Neo4jClient. However, at the same time, it is important for me to merge this implementation to the main repository later on. Taking this into account I wonder if we can discuss it in more details. Maybe, you can share your ideas with me.

From my perspective, we can even focus on point 1 for now and leave TransactionScope for later. It seems easier/faster to implement.

What do you think?

[cskardon]

hey @misiek1984,

You're right - part (1) is the main goal - I want to unify everything - and to that end there are 2 things I want to get into Neo4jClient 4.x - first is transaction support that is the same for all the versions - Core / Full etc

The second is to look into updating the driver underneath the bolt implementation to support Neo4j 4.0.

There is a 4.x branch which currently is in a nicer place from the pov of developing, and I think might have the TxScope removed. I'm happy to discuss the ideas I have - they're rough and not finalised, but would go in the right direction.

[misiek1984]

@cskardon,

Thanks for the quick response. If we can get rid of TransactionScope, it should be a little bit easier. To confirm my understanding. When I think about non-transactionscope way I have in mind something like:

var client = new GraphClient();
client.Begin();
try
{
   // Query and/or modify a graph in any way you want.
   client.Commit();
}
catch(Exception ex)
{
    client.Rollback();
}

Is our understanding the same on this very high level?

[cskardon]

I planned to have the Transactions on a different endpoint:

var writeTransaction = client.BeginTransaction(TransactionMode.Write);
var readTransaction = client.BeginReadTranscation();
var writeTransaction = client.BeginWriteTranscation();

With the GraphClient constructor optionally taking an ITransactionHandler - this would (by default) be a non TransactionScope based handler - but would allow for the injection of a different handler at a later date.

Commit and Rollback are good - they follow with the Neo4j way of doing it, so keeps it consistent.

Definitely get rid of TransactionScope, that's something I can put back in later if it's needed - and as long as there is a way to do it via injection that makes life a lot easier.

Does that make sense?

[misiek1984]

Yes, endpoints proposed by you looks ok.

As to ITransactionHandler it is a good idea. I tried to extend 3.X version of Neo4jClient in order to implement transactions for .Net Core and it turned out that there is no extension point.

Am I right that ITransactionHandler should replace existing transactions managers?

[cskardon]

Maybe ITransactionManager is a better name - the idea would be to replace them - yes - so if the TransactionScope is removed there pretty much isn't any transaction support at all.

I envisaged a DefaultTransactionManager that for the Bolt graph client simply chains to the underlying Neo4j.Driver and for the Http one a simple system.

The default should just work for Core/Full etc as it won't be relying on anything - and means that the codebase can finally be unified properly

[jschmidtWK]

Could you support nested transactions with these endpoints ?

[jpr7]

Hi, any news about transaction support in .NET core or .NET 5?
Thanks!