sakopov / dapper.ambientcontext Goto Github PK

Hi

This library almost looks perfect for what I need, however there is one feature missing. In my current code (which has a dbcontext, dbcontextfactory, dbconnectionfactory) I pass in information about what db type it is through the connectionfactory (my app supports sqlserver and postgresql) which flows down to the dbcontext. The reason for this is differences in sql needed for different db server types.

Is there any interest in adding a string property (Info) to the IDbConnectionFactory, IAmbientDbContext, and AmbientDbContext? I would be happy to create a PR for this.

What is the main difference between using Dapper.AmbientContext and using TransactionScope? The AmbientContext seems to have the same functionality as TransactionScope.

Sorry, I'm not sure if this is appropriate to open an issue for. Is there a way to integrate Dapper command extensions with this? Such as with Dapper Plus commands off of IDbConnection like BulkInsert?

Only way to do it seems to be ((AmbientDbContext)Context).DapperExtensionsCommand

This should be pretty easy.

1. Create context storage implementation on top of AsyncLocal<>.
2. Remove data marshaling wrapper.
3. Stop storing cross-reference key in the context storage. Store immutable stack directly in context storage instead.
4. Update tests.
5. Update documentation.

Hi, first of all i want to glad you. This project is amazing.

I'm having a connection leak because i can't dispose my context when i use a async methods.
When i dispose show me this message: "Could not dispose ambient database context because it is not the active ambient database context. This could occur because ambient database context is being disposed out of order."

This is a example of my usage.

 public async Task Handle(SimulateFinishedEvent message, CancellationToken cancellationToken)
  {
            using (var mroContext = this.contractsRepository.Context)
            {
                var contract = await this.contractsRepository.GetContractByIdAsync(mroContext, message.ContractId)
                                   .ConfigureAwait(false);
                var client = await this.clientsRepository.GetClientByIdAsync(mroContext, contract.ClientId)
                                 .ConfigureAwait(false);
                using (var contractContext = this.scenariosRepository.TransactionContext(message.ContractId))
                {
                    var scenario = await this.scenariosRepository
                                       .GetScenarioByIdAsync(contractContext, message.ScenarioId)
                                       .ConfigureAwait(false);
                    var project = await this.projectsRepository
                                      .GetProjectByIdAsync(contractContext, scenario.ProjectId)
                                      .ConfigureAwait(false);

                    var messageReply = new
                    {
                        clientId = contract.ClientId,
                        clientName = client.Name,
                        contractId = contract.Id,
                        contractName = contract.Title,
                        projectId = scenario.ProjectId,
                        projectName = project.Title,
                        scenarioId = scenario.Id,
                        scenarioName = scenario.Name
                    };

                    await this.simulationHubClients.All.SendAsync("scenarioSimulationFinished", messageReply)
                        .ConfigureAwait(false);
                }
            }
        }

When i have multiples connections simultaneous my problem happen.

When AmbientDbContext is disposed it removes disposed connections from the stack in storage, but doesn't remove the stack itself. Overtime, empty stacks accumulate and take up process memory.

This is not an issue with Dapper.AmbientContext, but rather that the latest version 1.4.0 is referencing Dapper 1.50.2 which in turn references System.Data.SqlClient (>= 4.1.0) which leaks according to #13422.

To fix, Dapper.AmbientContext should be updated to use Dapper 1.50.4. In addition, it should start targeting .NETStandard 2.0 to match Dapper itself.