Pergunta

Existe um método fácil de acessar dados de configuração baseada em System.Configuration personalizados através de uma interface thread-safe sem a necessidade de cada contexto de execução de carga / recarga informações de configuração que seria computacionalmente pesada?

aulas System.Configuration, como a maioria (todos?) Outras classes em documentação da biblioteca .Net, da Microsoft, são anotadas com as seguintes informações thread-segurança:

Qualquer público estático (compartilhadas Na Visual Basic) os membros desse tipo são segmento seguro. Os membros de instância não são garantidos para ser thread-safe.

Por minha leitura disto, o ConfigurationSection objetos retornados do ConfigurationManager.GetSection(string) e outros métodos semelhantes (por exemplo OpenExeConfiguration(string exePath).GetSection(string)) não deve ser assumido como thread-safe e, portanto, não deve ser utilizado por vários contextos de execução. Esta proíbe armazenar um ConfigurationSection em um singleton que de outra forma seria thread-safe porque, enquanto o acesso ao objeto seção pode ser seguro, os membros sobre o objeto em si não são seguros.

Várias chamadas para GetSection, no entanto, são susceptíveis de exigir novas instâncias ConfigurationSection dos arquivos de configuração e alocação de análise de re-que tem uma sobrecarga de alta considerando a configuração não é provável que a mudança já após a inicialização. Além disso, copiar os dados de configuração em outro objeto que tenha sido feitas thread-safe parece derrotar um dos principais benefícios da utilização do acesso built-in pacote de configuração em primeiro lugar (fácil de digitar-convertido e informações de configuração validada sem muito clichê código).

Assim, há uma maneira de usar System.Configuration de uma forma thread-safe sem recorrer ao excesso de análise, as atribuições de seções de configuração? Será que implementar seu próprio ConfigurationSection livrá-lo da falta de garantia fornecido pela Microsoft, mesmo que você está acessando-lo através das interfaces System.Configuration (e se assim for, como você implementá-lo para ser thread-safe, quando for necessário acesso a indexador da ConfigurationSection de base para acessar os dados configurado)?

Foi útil?

Solução

A instância retornou de GetSection não é thread-safe. Isso significa que você precisa adicionar o código de bloqueio, a fim de usá-lo em seu singleton.

Várias chamadas não re-analisar o arquivo, a menos que o arquivo foi alterado. Os dados são armazenados em cache na memória.

Seu problema de segurança segmento é facilmente resolvido através da utilização de bloqueio (não tenho certeza que você vai precisar, a menos que você está mudando a configuração em tempo de execução), e não há nenhum problema de desempenho.

Outras dicas

ConfigurationManager.GetSection (string) é um membro estático público, e uma vez que estados MSDN 'Qualquer membro público static (Shared no Visual Basic) os membros desse tipo são thread-safe', você pode assumir que é seguro usar.

Quanto ao desempenho, eu estaria disposto a assumir que MS tem feito isso muito já eficiente e usar apenas as suas funções como é. Lembre-se:. Otimização prematura é a raiz do mal

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top