Dicas de ADO.NET (GC.Collect, ADO.NET, múltiplos Adapters)

Conheça 4 dicas interessantes para melhor utilização do ADO.NET e Garbage Collector: Cuidado ao chamar o GC.Collect, Cancele dados pendentes quando estiver utilizando um DataReader, Evite checar o estado da propriedade state no objeto OLEDBConnection, Trabalhando com múltiplos Adapters

por David Pomarico

O método Collect do objeto GC (Garbage Collector) força a ocorrência da coleta de lixo e conseqüêntemente liberação de memória.

Porém este método deve ser evitado, pois é preferível deixarmos o próprio Garbage Collector decidir quando deve ser feita a coleta de lixo.

Mas quando realmente precisarmos realizar a coleta de lixo através do GC devemos tomar cuidado com a forma correta de chamar o método Collect, o que não é uma simples chamada de método. Veja:

- Chamamos o método Collect
- Precisamos esperar que todos os finalizes sejam rodados, liberando recursos
- Chamamos novamente o método Collect, pois a execução do finalize gera novas instancias a serem liberadas

Veja como fica :

GC.Collect
GC.WaitForPendingFinalizers()
GC.Collect

2ª Dica: ADO.NET: Cancele dados pendentes quando estiver utilizando um DataReader

Ao utilizarmos um DataReader pode acontecer eventualmente de desejarmos fechá-lo antes de termos navegado por todo o seu conteúdo.

O problema é que se simplesmente utilizamos o método close do datareader, este objeto força a navegação até o final dos dados antes que o close seja realmente realizado.

Assim sendo, se sabemos que existem mais registros no dataReader mas não desejamos lê-los, devemos cancelar a operação antes de fazermos o close, evitando assim um excesso de tráfego na rede.

Veja :

DR.Cancel
DR.Close

3ª Dica: ADO.NET : Evite checar o estado da propriedade state no objeto OLEDBConnection

Quando se utiliza conexão OLEDB, se você checar o estado da conexão (propriedade state) isso resulta em uma chamada para DBPROP_CONNECTIONSTATUS, uma função interna do OLEDB, o que vai gerar uma comunicação de rede para verificar se a conexão encontra-se aberta.

Desta forma, quando estivermos utilizando o OLEDBConnection devemos evitar a utilização da propriedade state. Podemos fazer uso do evento StateChanged e guardar em uma variável as mudanças de estado. Checando o valor desta variável estaremos checando o estado da conexão sem causar tráfego de rede.

Veja um exemplo :

Dim st As ConnectionState

Private Sub CN_StateChange(ByVal sender As Object, ByVal e As
System.Data.StateChangeEventArgs) Handles CN.StateChange

st = e.CurrentState

End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

If st = ConnectionState.Open Then
"Aqui algo pode ser feito
End If

End Sub

4ª Dica: .NET : Trabalhando com múltiplos Adapters

O DataAdapter possui um recurso já conhecido com relação a conexão : Ele é capaz de abrir e fechar a conexão sozinho quando fazemos o Fill de um dataset.

Assim sendo, o seguinte código funcionaria :

DA.Fill(ds1)
DA2.Fill(ds1)

Os dois adapters irão preencher o DS1 com as tabelas que estão buscando do banco.

O problema é que os adapters quando utilizados desta forma realmente abrem e fecham a conexão, então o código acima tem 2 aberturas de conexão e dois fechamentos, o que provoca um consumo desnecessário de recursos.

Vocês podem ainda pensar no uso do pooling. Devido ao pooling a conexão já estará aberta mesmo e não haverá prejuizo.

Ocorre que quando a conexão é pega do pooling é executada uma procedure chamada sp_reset_connection, que tem por objetivo resetar o status da conexão (características básicas da conexão). Essa procedure causará um consumo de recursos desnecessário.

Assim sendo a alternativa seria :

CN.open()
DA.Fill(ds1)
DA2.Fill(ds1)
CN.Close()

Você pode utilizar o Profiler do SQL Server para comprovar a diferença que estas instruções causam na comunicação com o servidor.