Implement a transaction factory service

[xal1983]

The current approach to creating transaction scopes is a bit limiting. You can define the isolation level and timeout in TransactionalAttribute, but this becomes a static value that you cannot alter without releasing a new build.
Also, the attribute uses the default value for isolation level defined in DataOptions. However, because the value is fixed in the contructor, there is no way to adjust this after the fact.

Describe the solution you'd like
Make "Unspecified" the default isolation level for TransactionalAttribute, so that at the time of creating the Transaction, if the value for the TransactionalAttribute is "Unspecified", we can use the global configuration value.
Create a TransactionFactory service that the TransactionalDataPortal calls in order to create the transaction. This service can receive information about the type, dataportal operation, method name and the instance of the transactional attribute, allowing for fine control of the creation of the transaction.

[rockfordlhotka]

The proposed solution would be a breaking change (changing the default behavior), so it would have to wait for CSLA 11.

An alternative would be to add a new isolation level in the enum of Custom, and that would trigger the use of the factory. What do you think about that idea?

I'm guessing we'd set up the factory as a lambda in the AddCsla configuration process - presumably in the DataOptions type.

Or as an interface type loaded via DI?

[xal1983]

Hi @rockfordlhotka
Yes, I was thinking an interface type via di, so we could also require other services, I would definitely need ApplicationContext for my use case at least.
I'm fine with creating a new value, in fact that was my initial suggestion, but after some thought edited the ticket to suggest Unspecified because it was already there. I don't see why this would be a breaking change though, right now if you don't specify anything in the attribute it will default to whatever is configured in dataoptions. The same would apply here, but instead of using what is in dataoptions when creating the instance of the attribute, you would check the attribute configuration at the time of creating the transaction and if it's unspecified then you would use the default one specified in dataoptions. Nothing would change for anybody that's specifying an isolationlevel or not specifying it at all unless I'm missing something.

Regardless of the approach, just being able to control the code that creates the transaction via a service, even if we don't change logic in TransactionalAttribute would suffice for me and I would be happy to restrict changes to just this.

Thoughts?

[praaline]

Hi @xal1983 - around the time of .NET 6 and the corresponding CSLA version if I remember correctly, we had come accross this library https://github.com/DotNotStandard/DataAccess/tree/main for connection / transaction management in conjunction with the DataPortal. We're using an updated version of it (added Oracle and Postgres support, and updated some functionality) but I would need to see if I can get permission from my employer to share the code. Is it something like this you're looking for?

[rockfordlhotka]

Certainly another modern option is to use DI for this purpose.

The server-side data portal ensures that your code is running in a DI scope, so any scoped services are automatically disposed at the end of the root data portal call. This means that you can use DI to inject an IDbTransaction object - which could be registered as a scoped service - and then all your data access code can use that transaction (and the database connection it references).

[xal1983]

Hi @praaline thanks for the feedback! However I'm referring to the usage of TransactionalDataportal, which internally creates a TransactionScope. The goal is not to swap that for manually managing transactions, just add a little flexibility to the creation of the TransactionScope, so we can fine tune isolation levels and timeouts depending on the action. Overall, I'm happy with using the TransactionalDataportal and don't wish to rewrite our library code, as that would require a lot of work and introduce risk.

[rockfordlhotka]

I do like the idea of an extensible opening to the TransactionalScope construct that allows people to create their own ADO.NET transactional service. This is probably how it should have been implemented in the first place, though I do like the simple/common options we have now for a direct and not complicated approach.