CORRECÇÃO: Conexão vazamento com comando parametrizado em ADO

Traduções deste artigo Traduções deste artigo
ID do artigo: 247757 - Exibir os produtos aos quais esse artigo se aplica.
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Expandir tudo | Recolher tudo

Neste artigo

Sintomas

Ao usar o Windows Foundation Classes para Java (WFC) e ADO e abrindo um conjunto de registros usando um comando com parâmetros de objeto, conexões que estão fechadas corretamente corretamente são colocados em pool e reciclados, resultando em vazamento conexões. Para contornar este problema, chame System.gc() após fechar a conexão ADO em seu objeto COM Java. Em situações normais, você não precisa chamar System.gc() após fechar uma conexão ADO para liberar a conexão.

Resolução

Esse problema é corrigido no service packs mais recentes para o Windows 2000 e MDAC 2.5.
  • Para resolver esse problema, obtenha o service pack mais recente para o Windows 2000. Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    260910Como obter o Service Pack mais recente do Windows 2000
  • Para resolver esse problema, obtenha o service pack mais recente para o Microsoft Data Access Components 2.5. Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
    293312INFO: Como obter o último MDAC 2.5 Service Pack
A versão em inglês dessa correção deve ter os seguintes atributos de arquivo ou posteriores:
File name       Date        Size      Version      
-----------------------------------------------------
Msado15.dll     1/26/2000   329KB     2.12.4926.0
				

Situação

A Microsoft confirmou que este é um problema no Microsoft Data Access Objects2.1 SP2 e 2.5. Esse problema foi corrigido primeiro no Microsoft Data Access Components 2.5 Service Pack 2 e Microsoft Windows 2000 Service Pack 2.

Mais Informações

Esse problema de pooling de conexão/sessão ocorre quando todas as condições a seguir estão presentes:
  1. Microsoft Data Access Objects 2.1 SP2 é instalado.
  2. Um objeto Command do ADO com parâmetros é usado.
  3. O objeto COM Java está hospedado no MTS ou COM +.
  4. O objeto COM Java cria um conjunto de registros desconectado.

Passos para reproduzir o problema

  1. Criar um projeto de objeto Java COM chamado ConnLoss com Visual J++ 6.0 usando o seguinte código:
    import com.ms.wfc.data.*;
    
    public class ConnLoss
    {
      // Modify this connection string to point to a running SQL Server.
      private static String m_connect = 
        "Provider=SQLOLEDB;Server=(Local);Database=Pubs;UID=sa;PWD=;";
      public com.ms.wfc.data.adodb._Recordset 
        FindAuthorsLastName( String au_id, boolean fCallGC )
      {
        Connection conn = null;
        Command cmd   = null;
        Recordset rs  = null;
        try
        {     
          // Open connection to SQL Server.
          conn = new Connection();
          conn.setCursorLocation( AdoEnums.CursorLocation.CLIENT );
          conn.open( m_connect );
          
          // Prepare command object.
          cmd = new Command();
          cmd.setActiveConnection( conn );
          
          cmd.setCommandText( "select au_lname from authors where au_id=?" );
        
          cmd.getParameters().append( 
            cmd.createParameter( "au_id", 
                       AdoEnums.DataType.VARCHAR,
                       AdoEnums.ParameterDirection.INPUT,
                       20, au_id ) );
          
          // Execute command.
          rs = cmd.execute();
          
          // Disconnect recordset and close connection.
          rs.setActiveConnection( (Connection) null );
          conn.close();
          
          // Call gc if requested.
          if (fCallGC) System.gc();
          
          // Return disconnected recordset.
          return (com.ms.wfc.data.adodb._Recordset) rs.getDataSource();
          
        }
        catch( AdoException adoEX )
        {
          // Log errors here.
        }
        return null;
      }
    }
    					
  2. Adicione o objeto COM Java para MTS ou o pacote COM +.
  3. Ligue para o objeto COM Java com o seguinte do Microsoft Visual Basic para código Applications (VBA):
    Sub TestConnLoss()
    Dim objCL As Object
    Dim i As Long
    Dim rs As ADODB.recordset
      set objCL = CreateObject("ConnLoss.ConnLoss")
      For i = 1 To 100
        Set rs = objCL.FindAuthorsLastName("756-30-7391", False)
        Debug.Print rs.Fields("au_lname").Value
        rs.Close
        Set rs = Nothing    
      Next i    
    End Sub
    					
  4. Executar o Monitor de desempenho do Windows NT na máquina onde o SQL Server 7.0 está localizado e monitorar conexões de usuário em contador de desempenho Estatísticas do SQL Server: geral .
  5. Execute o código de cliente do VBA. Neste ponto, 100 conexões de usuário são gerados pelo código conforme relatado pelo Monitor de desempenho do Windows NT, indicando que o pooling de sessão OLE não está funcionando corretamente para o provedor SQL OLE usado pelo objeto COM Java.

  6. Altere o segundo parâmetro da FindAuthorsLastName como True para ativar o código System.gc().
  7. Pare e reinicie o pacote MTS ou COM +.
  8. Execute o código do cliente VBA uma segunda vez.
Neste ponto somente algumas conexões de usuário são geradas pelo código, indicando que o pool de sessão OLEDB está funcionando corretamente para o provedor SQL OLE usado pelo objeto COM Java quando System.gc() é chamado.

Observação : chamada System.gc() afeta significativamente o desempenho do objeto COM Java, portanto, chamar System.gc() em geral deve ser evitado ao desempenho é uma consideração. Por exemplo, o objeto comercial pode ser codificado para chamar somente System.gc() cada método 10 ou 100 chama para reduzir o por método impacto no desempenho de chamar System.gc(). Além disso, o uso de um objeto de comando com parâmetros poderia ser evitado por valores de parâmetro embutir em código em uma seqüência de caracteres SQL e não usando tokens de parâmetro como no exemplo acima; isso contorna o problema bem.

Propriedades

ID do artigo: 247757 - Última revisão: domingo, 23 de fevereiro de 2014 - Revisão: 3.0
A informação contida neste artigo aplica-se a:
  • Microsoft Data Access Components 2.1 Service Pack 2
  • Microsoft Data Access Components 2.5
  • Microsoft Visual J++ 6.0 Standard Edition
Palavras-chave: 
kbnosurvey kbarchive kbmt kbqfe kbhotfixserver kbbug kbfix kbmdac250sp2fix KB247757 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 247757

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com