Which is the best DI registration Scope for CloudTableClient class on ASP.NET Core [closed]

Question

I'm creating web application with ASP.NET Core 2.2 and Azure Table Storage. Since Microsoft provides us with CloudTableClient class in Azure Storage SDK, I will use the class with Dependency Injection(DI). However, in standard DI approach, there are three methods to decide registration scope such as AddScoped, AddTransient, and AddSingleton. My question is which registration scope is the best for CloudTableClient class. I thought AddSingleton is the best because connection pool starvation does not happen, and I will use it like attached sample code. But if using AddSingleton is bad in some perspective(i.e. perf, or reliability), I would like to get some advice.

//Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    //do something

    services.AddSingleton(provider =>
    {
        var settings = Configuration["AzureStorageConnectionString"];
        CloudStorageAccount storageAccount = CloudStorageAccount.Parse(settings);
        CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
        return tableClient;
    });

    //do something
}

//SampleController
public class SampleController : Controller
{
    private CloudTable _table { get; };

    public SampleController(CloudTableClient tableClient)
    {
        _table = tableClient;
    }

    public async Task<IActionResult> GetSample(string id)
    {
        //do something with _table
    }
}

Selinaselinda

It very much depends on your goals. There is no answer to this question – Backswept

Answer 1

AddScoped then it will create new client per request or AddTransient which will give you new instance each time you ask it. If you do static then only one instance will be served for all threads which could be an issue since instance dont give you guarantee that they are thread safe

Submerse

Thanks! Ah so CloudTableClient instance is not thread-safe.. ok. but in other perspective, If I choose AddScoped, is there possibility to cause connection pool starvation? When request finished, is the connection disposed unlike normal HttpClient? – Selinaselinda

@user3395471 you could hit table storage limits learn.microsoft.com/en-us/azure/storage/common/… – Submerse

Ok. But what about the possibility of running out of sockets on the client side? If I choose AddScoped and everytime CloudTableClient instance is created, do you think that leads to occasional running out of sockets on the client side? – Selinaselinda

@Selinaselinda everything is possible but then it would be good problem to have since it means you have tons of users. and problem will be not with connection but simply performance – Submerse

yeah you are right.then I will use AddScoped. thank you! – Selinaselinda

Answer 2

Per the published performance tips, using a singleton is the correct way of implementing a client.

Each DocumentClient and CosmosClient instance is thread-safe and performs efficient connection management and address caching when operating in direct mode. To allow efficient connection management and better performance by the SDK client, it is recommended to use a single instance per AppDomain for the lifetime of the application.

Disavow

I think that is the case of Cosmos DB Client. What about the Table Client in Azure Storage SDK? – Selinaselinda

@Selinaselinda you shall use Microsoft.Azure.Cosmos.Table NuGet package, which supports both CosmosDB and Azure Table storage on both .NET Core and .NET Framework – Surround