Correct setup of dependency injection for Windows Service & asp.net framework?

[ajohnstone-ks]

I'm a bit unclear on the proper configuration of Csla & the service provider when using the server data portal methods.

Currently we are doing this to set it up, both in a Windows Server application (which uses the Local data portal only) and on our Asp.net framework application which hosts the remote data portal our desktop clients use.

var container = new UnityContainer();
// Configure the container, including IDbConnection as a trainsient.
var provider = new Unity.Microsoft.DependencyInjection.ServiceProviderFactory(container);
ApplicationContext.DefaultServiceProvider = provider.CreateServiceProvider(container);

I think we are seeing some connection leaks though, as I've had to restart the Windows Service as it was getting timeouts getting a SqlConnection from the pool. I think our remote data portal application server has the same issue as well, as things slow down over time and we need to restart it.

I think the issues crop up slowly over time as we've only just started converting things from the old way we got a connection to using [Inject] for our dependencies, but I'd like to verify that we are setting things up correctly so that, in the end, the UnityContainer which is created by the ServiceProvider is being deposed after every server side data portal operation.

Is the above correct, or am I missing something?

[rockfordlhotka]

CSLA doesn't manage the DI container in any way. It just uses the DI container.

In other words, whether the DI container is disposed or not is 100% up to the container (or you?).

[dazinator]

Is there some place we're supposed to add code to create the scope instead of letting Csla do it for use in a remote data portal host application (asp.net), and then dispose it?

Yes, if your remote application host is not asp.net core then you'll need to add code to your incoming request pipeline / processing to grab your platforms IServiceProvider and create a scope around processing of a request. For example for an OWIN based host you can add this logic to the OWIN middleware pipeline.

[ajohnstone-ks]

@rockfordlhotka I did see that, but it wasn't clear to me if that would solve our issue or not. When you say aspnet, do you mean .net framework or netcore? We're still on .net framework.

[dazinator]

If you are using legacy asp.net as a host you'll have to remind me - does legacy aspnet even have an IServiceProvider? Or do you build your own?

[ajohnstone-ks]

@dazinator You can get IServiceProvider by adding some nuget packages, but I don't think asp.net FW will know anything about it.

[ajohnstone-ks]

@rockfordlhotka So I think I have some things to try for the remote data portal hosted in asp.net framework, but I'm still not clear on where I would need to look to fix things in the Windows service.

Basically the service spins up a bunch of threads, and each of those threads will use a business object (typically a command) to do some work. This is all done in local data portal mode, so client & server are the same physical tier. I think this could be an issue on the desktop client app as well, but AFAIK we don't actually create an disposables in any logical server side code on the client.

It seems like something would need to happen soon after the transition to the logical server side code is made, but before Csla actually invokes the Create/Insert/Update/Delete/Fetch methods, and then dispose the scope before the transition back to the logical client side code.

Any tips on where to start looking for this?

[dazinator]

@ajohnstone-ks
See this: https://stackoverflow.com/questions/63017117/asp-webforms-with-system-web-http-api-controllers-constructor-dependency-inject

You'd need to be doing something similar to that to ensure an IServiceScope scope was created per request. You'd then need to call the csla application context extension method for setting the current scoped service provider to your ServiceScopes IServiceProvider at the start of the request - if this isn't set, csla will use the default IServiceProvider which I can see you are setting but this won't be created / disposed per request.

[dazinator]

@ajohnstone-ks
Without creating a scope per request and telling csla what it is, csla will be falling back to the default service provider which will cause you issues where services won't be created / disposed per request, so this ties up with the issues you are reporting.

[ajohnstone-ks]

Yes, it looks like Csla will get a new scope created, but its not disposing it, so it leaves the connection around.

[rockfordlhotka]

Maybe what's needed, in a 5.4.x patch, is to have a method in ApplicationContext to dispose (and clear) the current scoped provider. Then you could implement IInterceptDataPortal and call that method on complete?

This would enable @ajohnstone-ks to meet his needs I think.

@dazinator would not use this capability, because you are controlling your own scope(s).

However, @dazinator, the current implementation probably doesn't work for you at all, because ApplicationContext only understands one scope at a time, so there's no real way to have multiple scopes for different forms, etc. Isn't that a problem?

[dazinator]

so there's no real way to have multiple scopes for different forms, etc. Isn't that a problem?

I used the pattern in an xamarin android application and android models UI navigation as stack of screens. The current screen showing on your phone is the one on top of the stack. Therefore there is only ever one active screen at a time. Think Windows forms modal dialogs where this would also hold true. This equates to one active scope at a time.

However AFAIK Csla doesn't impose this constraint - there is no reason right now why you can't have multiple active scopes. When you set the current scope IServiceProvider into application context I beleive (havent checked in a while) that the context manager should use something like AsyncLocal to propagated that field. Therefore different threads can have different scopes. If you have a single thread and you are switching between active windows I grant you, you will want a different way of either modelling or managing your scopes to suit your architecture.

[ajohnstone-ks]

@rockfordlhotka Well, what I'd really need is a way to check if scope is null or not; if it is, I can create it and put it into a field in the interceptor. Then on complete if its not null dispose it.

Putting the interceptor aside, ideally I know that we just switched from logical client to logical server, and be able to execute code then (on the server, if the client & server are on physically different machines). Then I can create a scope that's existence is tied to the running of the logical server side code and cleanup just before that server code returns.

@dazinator Our WinForms app is an MDI app, so we have multiple forms open at the same time. We actually started implementing an MVVM architecture into it based on the MVVM architecture we used for our Xamarin.Forms app, so aside from single page / MDI they work in a similar manner (navigation & dialog services, etc). Aside from application startup which bootstraps the container, and a Page factory which uses the container to build Forms/Pages & their VMs, nothing in our application knows anything about scopes or containers.

[dazinator]

Hi, When your remote data portal runs locally, it means the dependencies CSLA will want to inject are from some scope within your existing application. Due to this, your application has more say in how it arranges its DI scopes - I dont think CSLA should take control of creating seperate DI scopes within your local application - one per local DP operation for example. On a remote server, serving requests from multiple clients, there is a natural "per request" scope for each client and so this makes sense- and you configure your services lifetimes with this model in mind. When there is no remote server however, and the DP runs locally in your own application - your application needs to supply scopes to csla. For example perhaps in your Windows forms application, you want each new window to run in its own scope - so that when the window closes, any dependencies injected into will be disposed (db context etc). Perhaps you have some background jobs - each of those jobs can have its own scope so anything activated within the job will used dependencies scoped to that job and they will all be cleaned up when the job finishes. You tell csla what scope its operating within, and that impacts which dependencies will be consumed by Csla. This allows your application to control where it creates scopes so you can create scopes that last longer than a single DP invocation.. Therefore with the windows forms example, you'd need to figure out: Do you want to use scopes? If not, csla can use your top level IServiveProvider - but make sure you don't register any IDisposable services because they won't ever be disposed. For your background threads example, if each thread needs its own instances if dependencies then consider creating a scope per thread and having that thread do any DI from that scope. Hope this helps

…

On Mon, 14 Dec 2020, 19:43 ajohnstone-ks, ***@***.***> wrote: @rockfordlhotka <https://github.com/rockfordlhotka> So I think I have some things to try for the remote data portal hosted in asp.net framework, but I'm still not clear on where I would need to look to fix things in the Windows service. Basically the service spins up a bunch of threads, and each of those threads will use a business object (typically a command) to do some work. This is all done in local data portal mode, so client & server are the same physical tier. I think this could be an issue on the desktop client app as well, but AFAIK we don't actually create an disposables in any logical server side code on the client. It seems like something would need to happen soon after the transition to the logical server side code is made, but before Csla actually invokes the Create/Insert/Update/Delete/Fetch methods, and then dispose the scope before the transition back to the logical client side code. Any tips on where to start looking for this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1983 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYHROGVOE4BHV5KW7KF53TSUZTGDANCNFSM4U27FNYA> .

[ajohnstone-ks]

@ajohnstone-ks
I am thinking one solution might be..

1. Allow a user to set the current scoped SP in csla application context (we have this already in place today)
2. If csla detects that this is set, the DP will use it without creating a scope itself. (Which is what happens today)
3. If csla detects that it isn't set, csla can get the current IServiceProvider (it does this today), and create a scope itself (it doesn't do this bit), around the DP operation running locally, disposing of the scope one its complete. This would give you the behavior I think you are after, and the ability to control scopes more when needed.

I think its something like this that we need, open to other alternatives.
@rockfordlhotka is the best person to comment on how this kind of thing might be implemented. Would this work for you?

If I am following, I think what you are saying is:

• current scoped SP = ApplicatoinContext.ServiceProviderScope (correct?)
• If ServiceProviderScope != null, do nothing
• If ServiceProviderScope == null, ServiceProviderScope = DefaultServiceProvider.GetRequiredService().CreateScope().ServiceProvider (for Csla 5.4.0)

And if #3 is happened, dispose the scope.

I would agree; I think the scope checking & creation should be done after moving from logical client to logical server, and cleanup just before returning to logical client.

That's actually exactly what I had been expecting Csla to do when we implemented the injection. This would allow disposable resources needed in the logical server code to be disposed of before returning to the logical client side, which I think is a pretty reasonable expectation. And if people can override that default behavior, they can do so.

[ajohnstone-ks]

@rockfordlhotka @dazinator That's exactly what the interceptor I coded does; it was just a bit tricker b/c I couldn't look at the values for DefaultServiceProvider/ServiceProviderScope, so I had to have a static method to configure it on startup and track the created scope separately.

Very much appreciate both of you discussing this!

[ajohnstone-ks]

On a remote host, we wouldn't want the interceptor to run and create a new scope, because for example - asp.net core will already have created a perfectly good scope around the incoming DP request anyway.

I think a scope should still be created & disposed even in a remote host.

My reasoning is that there is time between when Csla would call Complete on an interceptor and the end of the asp.net request and then dispose the scope.

For most applications this will not be an issue, but under heavy load the connection being kept open & unavailable to other requests will matter, even if only for fractions of a second.

@rockfordlhotka I've created an issue for this as requested #1996

[rockfordlhotka]

Thank you for creating the issue @ajohnstone-ks. The great thing about this solution with the interceptor, is that you can use the interceptor on the server if you'd like - it'll be a configuration choice between a no-op interceptor and the per-call scope interceptor, regardless of where the server-side data portal is running.

btw, can you share the code from your custom interceptor? Perhaps in the issue instead of here, as it would be useful for reference in the future.

[ajohnstone-ks]

@rockfordlhotka Yes, I fully agree this is a great solution as it is fully customizable.

I've added code similar to the one I implemented to the issue; its a bit easier because you can get DSP & SPS from within Csla and I've added some points to allow someone to override Initialize & Complete if they want to add behavior in addition to keeping the scope behavior. I've also updated the ticket to reflect that it shouldn't be configured by default for a remote application server, since that doesn't seem to be desired there.