Why is a new DI scope created when using LocalProxy

[swegele]

Currently, the LocalProxy automatically creates a new DI scope if LocalProxyOptions.CreateScopePerCall = true which is the default setting.

If it is defaulted to true, then presumably that is the recommended path. What was the original problem that the new scope solves? If I can understand that, then I should be able to understand the consequences of setting the option to false.

[TheCakeMonster]

I think it's so that you can create things like database connections and data store contexts and have them used across all of the objects in an object graph. If a parent creates a connection, then using that same connection for all of the children, grandchildren and so on is really useful. Reuse of the same connection/context avoids any attempt to perform escalation to a distributed transaction.

Avoiding escalation is not only an efficiency gain, it's vital in .NET Core. .NET Core suffers from the hidden .NET Standard fib: that PlatformNotSupportedException is an allowed implementation of an API. Sigh. .NET Core runtimes throw PlatformNotSupportedException during an attempt to escalate a standard transaction to a distributed one. Despite distributed transactions looking like they should work because the moving parts are part of the .NET Standard API surface, they are not implemented on .NET Core, even after all of this time.

There's an issue in the dotnet repo that tracks this problem. It has had an update suggesting this will be fixed (on Windows only) in .NET 7.0. However, the issue has been around long enough - and we've been batted away frequently enough - that I will wait and see rather than assume it'll happen. Indeed, this issue replaces several others that have simply been rejected as too difficult, and closed. It's been a bit of a hot potato. dotnet/runtime#715

[swegele]

I can already create database connections and data store contexts to use across all the objects...without having an additional scope.

But I guess your saying the creation of an additional scope is to ensure all server side operations are UNIQUE/ISOLATED FOR EACH CALL across the local dataportal?

If I'm understanding that correctly, then one BSS client could make multiple asynchronous calls across the data portal and each one of them would be in their own formal scope rather than sharing a scope with each other. Is that correct?

And that means that if I set the CreateScopePerCall = false then I would have to manually manage that instead of getting it out of the box?

[TheCakeMonster]

Yes, that's right. Calls to the server are automatically isolated, and the connections are managed for you by DI. It should result in less code for the same functionality. Reducing plumbing code is one of the main goals of CSLA.

[rockfordlhotka]

The CreateScopePerCall default is different in different runtimes.

• aspnetcore - false
• stateful clients (blazor/wpf/etc.) - true
• console apps - true

Because aspnetcore (MVC, Razor Pages, etc.) already use a scope that lasts only the length of time for the client request, no extra scope is necessary.

Because all other environments use a scope that lasts the length of time the app is running, a temporary scope is necessary for isolation of logically server-side data portal operations.

[rockfordlhotka]

One solution I can think of is to have the CreateScopePerCall value come from a provider (service), and that service - in aspnetcore - would use logic based on the accessibility of an HttpContext to determine whether the value should be true or false.

All other runtimes would use a service that always returns true.

[swegele]

That gets interesting in BSS though because builder.Services.AddHttpContextAccessor(); in program.cs causes HttpContext to be accessible (but it's not trustworthy and shouldn't be used which can really be misleading). That whole thing is a little kludgy.

That is related to what I was struggling with in how to send a signal to server side of LocalProxy to know that the call came from blazor circuit and not from an aspnet razor view (.cshtml). But hopefully when y'all put the LocalProxy back to having it's own ApplicationContextManager then that won't be needed and all will be well again.

Anyway, I was just curious. about what that feature/setting CreateScopePerCall was for and I think I get it now.