Visão Geral

Este artigo é sobre um novo recurso chamado recurso de ajuste automático para Hibernate que está disponível no IBM InfoSphere Optim pureQuery Runtime v3.1. Como o nome sugere, esse recurso automatiza os problemas mais comuns enfrentados por usuários do Hibernate. Ele automaticamente otimiza os padrões de acesso do banco de dados em cada caso de uso do aplicativo sem intervenção manual. Hoje, o processo de garantir que o padrão de acesso de banco de dados ideal seja usado em cada caso de uso de um aplicativo ORM é um processo manual, entediante e sujeito a erros, que consome um número significativo de horas por pessoa. Com esse recurso, otimizar o padrão de acesso do banco de dados de cada caso de uso leva a benefícios significativos do desempenho do sistema.

Este artigo aborda como configurar e usar esse recurso. Primeiro, descreve os problemas de estratégia de busca dos dados enfrentados pelos aplicativos ORM, e em seguida descreve como a solução pureQuery resolve o problema. Este artigo supõe que você conhece o Hibernate e que esteja usando Hibernate 3.2 ou superior. É possível aproveitar o ajuste automático do pureQuery para Hibernate sem alterar o código do aplicativo.

O primeiro e o segundo artigos da série trataram de acelerar aplicativos Hibernate e iBATIS respectivamente usando DB2® Static SQL e envio em lote heterogêneo do pureQuery. O primeiro artigo também abordou os seguintes dois tópicos:

• Uma revisão da plataforma pureQuery, que consiste em ferramentas de desenvolvimento, uma API Java, um tempo de execução e serviços de monitoramento que pode ser usados para visualizar métrica de desempenho e correlacionar instruções SQL com o código Java de origem.
• Descreve como é possível obter os benefícios do pureQuery sem usar a API do pureQuery, por meio dos recursos do DB2 Static SQL e envio em lote heterogêneo fornecido pelos Módulos de Integração da IBM.

Visão geral do recurso de ajuste automático do pureQuery para Hibernate

Esta seção aborda o recurso de ajuste automático disponível com o InfoSphere Optim pureQuery Runtime e como ele resolve a maioria dos problemas comuns de aplicativos Hibernate. Os problemas mais comuns enfrentados por usuários do Hibernate/ORM é que o aplicativo faz o seguinte:

• Emite instruções SQL demais para o banco de dados para muitos dos casos de uso do aplicativo. De fato, o número de instruções SQL emitidas pelo aplicativo pode alcançar as centenas ou milhares por caso de uso.
• Procura dados ou linhas demais no banco de dados para o que é exigido de um dado caso de uso de negócios.
• Emite instruções SQL demais e carrega dados ou linhas em excesso do banco de dados para o que é exigido de um dado caso de uso de negócios.

Todos os três cenários podem pressionar os recursos do servidor de banco de dados e podem tornar inaceitável o desempenho do aplicativo e do sistema de banco de dados.

Usuários consideram essas questões um grande problema quando lidam com aplicativos Hibernate/ORM. Também é o problema que encontram com maior frequência e no qual gastam mais tempo e esforço para resolver.

Os problemas de aplicativos Hibernate/ORM podem ser entendidos olhando o exemplo na Figura 1.

O aplicativo consiste no modelo de objeto de aplicativo (o primeiro modelo na Figura 1) que define o aplicativo em termos de objetos Java orientados a objeto. O modelo de relacionamento de entidade de banco de dados (o segundo modelo na Figura 1) descreve como os mesmos objetos são armazenados em um sistema de banco de dados relacional usando tabelas e relacionamentos de chave primária e chave estrangeira. A biblioteca do ORM fica entre essas duas camadas e converte dados entre os dois formatos.

Um modelo de objeto de aplicativo consiste em uma hierarquia de objetos interconectados. Para um caso de uso de aplicativo, a hierarquia inteira do objeto pode não ser necessária. Podem ser necessárias apenas aquelas partes da hierarquia com as quais o caso de uso lida. O desempenho do aplicativo sofre se a hierarquia inteira for carregada para cada caso de uso.

Definição do problema

Os mapeamentos ORM permitem uma única definição (em arquivos de mapeamento ou anotações) de como um objeto que é ligado a outro objeto na hierarquia deve ser carregado (rapidamente ou lentamente), e se deve ser usado uma junção SQL ou uma instrução SQL separada. Para um aplicativo Hibernate/ORM bem ajustado, em cada uso de caso de aplicativo, as configurações do relacionamento de um objeto com outros objetos (lento ou rápido) devem ser definidas de maneira exclusiva para garantir que não ocorra carregamento extra de dados. Além disso, as configurações ideais para a maneira como os dados devem ser recuperados do banco de dados (junção SQL ou instrução SQL separada) também deve ser definido separadamente.

Obviamente essas configurações (carregamento de dados rápido ou lento, e junção SQL ou instruções SQL separadas para recuperação de dados) para um único link no modelo de objetos podem ser diferentes em casos de uso, e especificar as configurações erradas em um caso de uso pode causar desempenho ruim.

Determinar manualmente essas configurações ideais para cada uso de caso pode ser um processo trabalhoso, especialmente em aplicativos grandes, e ainda mais quando o aplicativo lida com modelos de objeto complexos. Às vezes desenvolvedores recorrem a métodos de tentativa e erro em casos de uso no qual o desempenho é totalmente inaceitável, e podem ignorar outros casos de uso. Esse processo de otimização pode consumir muito tempo e recursos. Esse é o motivo pelo qual foi classificado pelos usuários como um problema que consome o maior tempo e esforço.

Solução - Recurso de ajuste automático do pureQuery para Hibernate

A solução de ajuste automático do pureQuery determina as configurações exclusivas ou ideais para cada link no modelo de objeto em cada caso de uso. Isso é feito analisando os padrões de uso de dados no caso de uso do aplicativo enquanto este é executado. Nas execuções seguintes do mesmo caso de uso de aplicativo, as configurações ideais são automaticamente colocadas no sistema, de mofo que o desempenho seja ideal. Novamente, nenhuma alteração de código é necessária para usar esse recurso e ele pode ser usado com aplicativos existentes.

Voltar para parte superior

A arquitetura do ajuste automático do pureQuery para Hibernate

A Figura 2 mostra a execução de alto nível de um aplicativo Hibernate com o recurso de ajuste automático do pureQuery para Hibernate.

O recurso de ajuste automático do pureQuery para Hibernate fica entre o aplicativo e o Hibernate, e analisa os dados buscados pelo Hibernate com base em solicitações de aplicativo. Também analisa o padrão de uso do aplicativo para esses dados. Com base na análise, o ajuste automático do pureQuery para Hibernate produz as configurações otimizadas. Em seguida, envia as configurações otimizadas ao Hibernate, para que o acesso ao banco de dados seja otimizado. As propriedades do ajuste automático do pureQuery para Hibernate controlam o processo de análise e otimização.

Voltar para parte superior

Pré-requisitos para usar o recurso de ajuste automático do pureQuery para Hibernate

Software

Para usar o recurso de ajuste automático do pureQuery para Hibernate, é preciso ter o seguinte:

• IBM InfoSphere Optim pureQuery Runtime 3.1 ou superior. Se você não tiver, consulte a seção Recursos para obter um link de download do IBM Data Studio 3.1, que contém o Optim pureQuery Runtime. O pureQuery Runtime deve estar na mesma máquina que o IBM Data Studio.
• IBM Data Server Driver para JDBC e SQLJ 3.58 ou 4.7. Está disponível com o IBM Data Studio, ou consulte a seção Recursos para obter um link para download.
• Hibernate 3.2 ou superior (foi testado com 3.2. e 3.3.1).

Bancos de dados suportados

O recurso de ajuste automático do pureQuery para Hibernate funciona quando o aplicativo está acessando qualquer um dos seguintes sistemas de bancos de dados:

• DB2 para Linux®, UNIX® e Windows® V8.2, Fix Pack 11 ou posterior
• DB2 para Linux, UNIX e Windows V9.1, V9.5 ou V9.7
• DB2 para z/OS® V8 ou posterior
• Informix® V11.10 ou posterior

Exemplo de aplicativo usado neste artigo

O arquivo AutoTuningSample.zip incluído neste artigo contém um aplicativo de amostra que pode ser usado para experimentar esse recurso, se você estiver usando o Hibernate 3.2 ou superior.

Voltar para parte superior

Ativando o recurso de ajuste automático do pureQuery para aplicativos Hibernate

Configure o caminho da classe

O aplicativo de amostra usa Hibernate 3.3, o gerenciador de entidade do Hibernate e as anotações do Hibernate. Portanto, para compilar o aplicativo, é preciso ter os seguintes arquivos jar no seu caminho de classe com os demais arquivos jar exigidos pelo aplicativo:

• hibernate3.jar
• hibernate-entitymanager.jar
• dom4j-1.6.1.jar
• hibernate-annotations.jar
• hibernate-commons-annotations.jar
• log4j-1.2.15.jar
• javassist-3.4.GA.jar
• antlr-2.7.6.jar
• commons-collections-3.1.jar
• slf4j-api-1.5.2.jar
• slf4j-log4j12-1.5.2.jar
• commons-logging-1.0.4.jar
• jta1.1.jar
• ejb-persistence.jar

Para usar o recurso de ajuste automático do pureQuery para Hibernate, também é preciso ter os seguintes arquivos jar no caminho de classe:

• O driver do IBM Data Server para JDBC, e arquivos jar do SQLJ 3.58 ou 4.7 (os arquivos jar do db2jcc).
• Os arquivos jar do pureQuery pdq.jar, pdqmgmt.jar e pdqhibtune.jar. Os arquivos jar são parte da instalação do pureQuery Runtime.

Preparar o banco de dados do aplicativo de amostra

Siga as seguintes instruções para preparar e executar o aplicativo de amostra.

1. Crie um banco de dados chamado TRADEDB. Hibernate cria automaticamente as tabelas necessárias.
2. Descompacte o arquivo AutoTuningSample.zip e importe o aplicativo de amostra como um projeto Java na sua área de trabalho do IBM Data Studio.
3. Inclua os mesmos arquivos JAR listados em Configure o caminho da classe no caminho do desenvolvimento do projeto. Para incluir os arquivos jar do pureQuery e IBM Data Server para JDBC e SQLJ no caminho de desenvolvimento do projeto, clique com o botão direito no projeto e selecione Data Access Development > Add Data Access Development Support. Selecione a caixa de seleção Add pureQuery support to project.
4. Edite o arquivo hibernate.cfg.xml e digite o nome de usuário e senha para acessar o banco de dados. No aplicativo de amostra, é mostrada a Listagem 1.
   
   Lista 1. Propriedade de nome de usuário e senha do banco de dados em configuração
   

   <property name="hibernate.connection.username">xx</property> <property name="hibernate.connection.password">xx</property>

   
   
   
5. Execute a classe tradeApp.utils.PopulateDatabase clicando com o botão direito na classe, selecionando Run as > Java application no IBM Data Studio para preencher o banco de dados com as entidades.

Entidades e casos de uso do aplicativo de amostra

O aplicativo de amostra usa um modelo de objeto de aplicativo que consiste nas duas entidades a seguir:

• Account, que reside no arquivo tradeApp.domain.Account.java. Account é uma entidade esqueleto para fins de demonstração, e tem os seguintes atributos: name, age, uma coleção de orders e ID (que é a chave primária).
• Order, que reside no arquivo tradeApp.domain.Order.java. Order também é uma entidade esqueleto para fins de demonstração e tem os seguintes atributos: orderDate, orderState a Account que fez o pedido e ID (que é a chave primária).

O aplicativo consiste nos dois casos de uso a seguir:

• Visualizar Pedidos
• Processamento de pedido no fim do dia

O caso de uso Visualizar Pedidos é uma implementação de um cliente visualizando pedidos, e está localizado no arquivo tradeApp.dao.AccountDao.java, como mostra a Listagem 2.

        
public List <Account> queryAccounts(int accountId) {
    Criteria query = sess.createCriteria(Account.class);
    query.add(Restrictions.eq("id", accountId));

    List<Account> accounts = query.list();
    sess.close();
    return accounts;
    }

Aqui você criou uma consulta para retornar uma conta particular como identificada por accountId. Em seguida, você emite a consulta para o banco de dados que está chamando o método de lista na consulta e retorna a conta correspondente. O responsável pela chamada desse método está no arquivo TradeApp.java do programa cliente, que em seguida exibe os dados da conta e seus pedidos no console. O código para exibir a conta e seus pedidos está no arquivo tradeApp.view.View.java.

A implementação do caso de uso de Processamento de pedido no fim do dia está localizada no arquivo tradeApp.dao.OrderDao.java, como mostra a Listagem 3.

public void processOrders(java.sql.Date date) {
    Query query = session.createQuery("from Order o where o.orderDate = ? ");
    query.setDate(0,date);
		
    List<Order> orders = query.list();
    for (Order o : orders) {
        // Upgrade customer if reqd based on order value
	    Account a = o.getAccount();
	    a.upgradeCustomerIfRequired(); 
			
	    //set OrderState to IN_PROCESS
	    o.setOrderState("PROCESS"); 
			 
    }
		
    // push changes to database
    /* session.flush(); */

    session.close();
}

Aqui você cria uma consulta para retornar todos os pedidos em uma data específica, e no qual OrderState seja NEW. Em seguida, você emite a consulta para o banco de dados que chama o método de lista na consulta. Você processa cada pedido correspondente e atualiza OrderState para PROCESS, e também atualiza a conta se necessário. Para salvar suas alterações no banco de dados, você chama o método de limpeza na sessão. Essas linhas estão comentadas no código para permitir executar o aplicativo repetidamente.

As propriedades do recurso de ajuste automático do pureQuery para Hibernate

O arquivo hibernate.properties contém as propriedades do recurso de ajuste automático e está localizado na pasta src. Elas são mostradas na Listagem 4.

pdq.hibernate.fetchMode.analyze=ON 
pdq.hibernate.tunedSettings= pureQueryFolder/tunedSettings.xml
pdq.hibernate.fetchMode.optimize=ON

• A propriedade pdq.hibernate.fetchMode.analyze é usada para ligar ou desligar a análise de padrões de uso de dados enquanto o aplicativo está executando.
• A propriedade pdq.hibernate.tunedSettings controla onde as configurações de modo de busca otimizado são salvas quando pdq.hibernate.fetchMode.analyze está configurado para ON. Também especifica de onde as configurações de modo de busca otimizadas devem ser recuperadas quando pdq.hibernate.fetchMode.optimize está ON.
• A propriedade pdq.hibernate.fetchMode.optimize é usada para ligar ou desligar o uso de modos de busca otimizados do Hibernate quando o aplicativo está executando.

Observação: Em um ambiente de produção ou de servidor de aplicativos no qual pode ser necessário alterar os valores das propriedades do recurso de ajuste automático imediatamente, sem reiniciar o aplicativo, pureQuery Runtime suporta a leitura dessas propriedades a partir de um repositório do pureQuery Runtime. O próximo artigo nesta série aborda esse aspecto.

Voltar para parte superior

Executar o aplicativo em Modo de Análise

Configure o argumento de JVM JavaAgent antes de executar o aplicativo. No IBM Data Studio, clique com o botão direito em TradeApp.java > Run As > Run Configurations. Na guia Arguments de Run Configurations, configure os argumentos de VM como -javaagent: < path of pdqhibernatetuneagent.jar > e clique em Run, como mostra a Figura 3.

Isso executa o aplicativo TradeApp. Quando o aplicativo tiver executado, um arquivo de configurações de modo de busca otimizado (tunedSettings.xml conforme definido na propriedade pdq.hibernate.tunedSettings) é produzido no local dado como o valor da propriedade pdq.hibernate.tunedSettings no arquivo de configuração.

A saída da execução é exibida na visualização de console do IBM Data Studio e é mostrada na Listagem 5.

SQL executed 203
-----------------------------------------------------------------------------------------
Execution count |        SQL Statement  
 1              select this_.id as id1_0_, this_.ORDERSTATE as ORDERSTATE1_0_,
 		this_.ORDERDATE as ORDERDATE1_0_,this_.ACCOUNT_ID as ACCOUNT4_1_0_ 
 		from DB2ADMIN.Orders this_ where this_.ORDERDATE=? and this_.ORDERSTATE=?
 		
 1              select this_.ID as ID0_0_, this_.NAME as NAME0_0_, this_.AGE as AGE0_0_
 		from DB2ADMIN.Accounts this_ where this_.ID=?
 		
 101            select orders0_.ACCOUNT_ID as ACCOUNT4_1_, orders0_.id as id1_,
 	        orders0_.id as id1_0_,orders0_.ORDERSTATE as ORDERSTATE1_0_,
 	        orders0_.ORDERDATE as ORDERDATE1_0_, orders0_.ACCOUNT_ID as ACCOUNT4_1_0_
 	        from DB2ADMIN.Orders orders0_ where orders0_.ACCOUNT_ID=?
 	        
 100            select account0_.ID as ID0_0_, account0_.NAME as NAME0_0_, account0_.AGE
                as AGE0_0_ from DB2ADMIN.Accounts account0_ where account0_.ID=?
-----------------------------------------------------------------------------------------
 

Como você pode ver, há 203 instruções SQL sendo executadas pelos dois casos de uso do aplicativo.

Voltar para parte superior

Inspecionando o XML de TunedSettings

Um fragmento do arquivo XML TunedSettings gerado na etapa anterior é mostrado na Listagem 6.

<?xml version="1.0" encoding="ISO-8859-1"?>
<useCases>
  <useCase>
    <entities>
      <entity name="tradeApp.domain.Account">
        <attribute name="orders" fetchMode="select" lazy="false">
          <tuning-info accept="true" fetchMode="subselect" lazy ="false"/>
        </attribute>
      </entity>
      <entity name="tradeApp.domain.Order">
        <attribute name="account" fetchMode="select" lazy="false">
          <tuning-info accept="true" fetchMode="select" lazy ="true"/>
        </attribute>
      </entity>
    </entities>
  <id>java.lang.Thread.getSta..................................</id>
  </useCase>
  <useCase>
    <entities>
      <entity name="tradeApp.domain.Order">
        <attribute name="account" fetchMode="select" lazy="false"/>
          <tuning-info accept="true" fetchMode="join" lazy ="false"/>
        </attribute>
      </entity>
      <entity name="tradeApp.domain.Account">
        <attribute name="orders" fetchMode="select" lazy="false"/>
          <tuning-info accept="true" fetchMode="select" lazy ="true"/>
        </attribute>
      </entity>
      </entities>
      <hqls>
        <hql>
          <applicationHql>from Order o where o.orderDate = ? </applicationHql>
          <tunedHql>
             from Order o  left outer join fetch o.account  where o.orderDate = ?
          </tunedHql>
          <addedJoins>
            <join>left outer join fetch o.account</join>
          </addedJoins>
        </hql>
      </hqls>
      
  <id>java.lang.Thread.getSta..................................</id>
  </useCase>
</useCases>

O arquivo XML TunedSettings tem sugestões de otimização para os dois casos de uso a seguir.

• No primeiro caso de uso, a consulta ORM foi acionada na entidade tradeApp.domain.Account. Para este uso de caso, o atributo orders definido na entidade tradeApp.domain.Account é rápido e o modo de busca é selecionar. No entanto, as configurações ajustadas sugerem que essa entidade deve ser buscada rapidamente com o modo de busca subselecionar.

  Da mesma forma, para o atributo account definido em tradeApp.domain.Order era rápido, e o modo de busca era selecionar. No entanto, as configurações ajustadas desse atributo sugerem que ele deve ser buscado de forma lenta com o modo de busca selecionar.

• No segundo caso de uso, a Consulta ORM foi acionada na entidade tradeApp.domain.Order. Para este uso de caso, o atributo account definido na entidade tradeApp.domain.Order é rápido com o modo de busca selecionar. No entanto, as configurações ajustadas sugerem que essa entidade deve ser buscada rapidamente com junção.

  Da mesma forma, o atributo tradeApp.domain.Account é rápido e o modo de busca é selecionar. No entanto, as configurações ajustadas sugerem que ele deve ser buscado de forma lenta com o modo de busca selecionar.

  
  

  Mais além nesse caso de uso foi usado um HQL. A tag <applicationHql> contém o HQL usado pelo aplicativo, e a tag <tunedHql> contém o HQL otimizado para esse caso de uso, que inclui fundir account ao buscar order. O ajuste de HQL está restrito apenas a incluir junções de busca no HQL do aplicativo original. Isso porque, quando o Hibernate executa HQL/JPAQL, as junções precisam ser especificadas no próprio HQL/JPAQL, e junções especificadas nas configurações não são respeitadas.

Para desligar qualquer sugestão de otimização, se necessário, configure accept=”false” na tag tuning-info, como mostra a Listagem 7.

<tuning-info accept="false" fetchMode="select" lazy ="true"/>

Para desligar a sugestão de otimização HQL, se necessário, configure a tag <tunedHql> como vazia, como mostra a Listagem 8.

<hql>
    <applicationHql>from Order o where o.orderDate = ? </applicationHql>
    <tunedHql></tunedHql>
    ...

Voltar para parte superior

Executar o aplicativo com as sugestões de otimização

Execute novamente o aplicativo TradeApp. A saída da execução com Optimized Settings é exibida na visualização de console no IBM Data Studio e é mostrada na Listagem 9.

SQL executed 3
-----------------------------------------------------------------------------------------
Execution count |        SQL Statement  
 1                select this_.ID as ID0_0_, this_.NAME as NAME0_0_, this_.AGE as AGE0_0_ 
 	          from DB2ADMIN.Accounts this_ where this_.ID=?
 
 1                select orders0_.ACCOUNT_ID as ACCOUNT4_1_, orders0_.id as id1_,
 		  orders0_.id as id1_0_, orders0_.ORDERSTATE as ORDERSTATE1_0_,
 		  orders0_.ORDERDATE as ORDERDATE1_0_, orders0_.ACCOUNT_ID 
 		  as ACCOUNT4_1_0_ from DB2ADMIN.Orders orders0_ where 
 		  orders0_.ACCOUNT_ID=?
 
 1                select this_.id as id1_1_, this_.ORDERSTATE as ORDERSTATE1_1_, 
                  this_.ORDERDATE as ORDERDATE1_1_, this_.ACCOUNT_ID as ACCOUNT4_1_1_,
                  account2_.ID as ID0_0_, account2_.NAME as NAME0_0_, account2_.AGE as
                  AGE0_0_ from DB2ADMIN.Orders this_ left outer join DB2ADMIN.Accounts
                  account2_ on this_.ACCOUNT_ID=account2_.ID where this_.ORDERDATE=?
                  and this_.ORDERSTATE=?
---------------------------------------------------------------------------------------

Como você pode ver, o número de instruções SQL executadas é apenas três dessa vez, em comparação com 203 sem as sugestões de otimização de ajuste automático.

Voltar para parte superior

Configurando o recurso de ajuste automático do pureQuery para aplicativos Hibernate implementados em um WebSphere Application Server

Se o aplicativo Hibernate estiver implementado em um WebSphere® Application Server, todas as etapas permanecem as mesmas de antes, exceto pela etapa para configurar o argumento de JVM JavaAgent. A seção a seguir descreve como configurar o argumento de JVM de JavaAgent.

Configurando o argumento de JVM JavaAgent em um WebSphere Application Server

1. Abra o console administrativo e clique em Servers > Server Types > WebSphere Application Servers e clique em server1 como mostrado na Figura 4.
   
   
   Figura 4. Selecione o servidor no Console Administrativo do WebSphere
   
   
   
2. Nas propriedades do servidor, clique em Java and Process Management > Process definition conforme mostra a Figura 5.
   
   
   Figura 5. Selecione a definição de processo
   
   
   
3. Clique em Java Virtual Machine , como mostrado na Figura 6.
   
   
   Figura 6. Selecione Java Virtual Machine
   
   
   
4. Digite -javaagent: <Path to pdqhibtuneag.jar> em Generic JVM arguments , como mostra a Figura 7.
   
   
   Figura 7. Configurar argumento da JVM
   
   
   
5. Clique em Apply e, quando solicitado, salve as configurações na configuração principal. Reinicie o servidor pra que mudanças tenham efeito.

Voltar para parte superior

Conclusão

Neste artigo, analisamos problemas comuns enfrentados por aplicativos Hibernate, e como o recurso de ajuste automático do IBM InfoSphere Optim pureQuery para soluciona esses problemas. Este artigo também descreve como usar esse recurso com os aplicativos Hibernate (aplicativos Hibernate JPA e aplicativos nativos Hibernate).

Por meio do aplicativo de amostra, demonstramos a capacidade desse recurso de otimizar o acesso ao banco de dados, de 203 instruções SQL usadas para apenas 3 instruções. Isso oferece benefícios e ganhos de desempenho significativos para aplicativos do Hibernate e acaba com a necessidade de gastar tempo e esforço manual para obter os benefícios. Esses ganhos de desempenho se aplicam em ambientes JEE e J2SE.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Use um feed RSS para solicitar notificação sobre os artigos futuros desta série. (Descubra mais sobre feeds RSS do conteúdo do developerWorks.)
  
  
• Saiba mais sobre pureQuery lendo "Iniciação ao pureQuery (e-book).
  
  
• Saiba mais sobre os objetos de acesso a dados de método de anotação do pureQuery lendo o artigo do developerWorks Write high performance, Java data access applications, Part 1: Introducing pureQuery annotated method data access objects.
  
  
• Saiba mais sobre métodos sequenciais integrados do pureQuery lendo o artigo do developerWorksWrite high performance Java data access applications, Part 2: Introducing pureQuery built-in inline methods.
  
  
• Obtenha os recursos necessários na área de Information Management no developerWorks, para melhorar suas habilidades em uma grande variedade de produtos do IBM Information Management.
  
  
• Siga o developerWorks no Twitter.
  
  
• Acompanhe as demos on demand do developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidade avançada para desenvolvedores experientes.
  
  

Obter produtos e tecnologias

• Baixe e teste o IBM Data Studio 3.1., que inclui InfoSphere Optim pureQuery Runtime para uso por desenvolvedores.
  
  
• Faça download do archive IBM Data Server Driver para JDBC e SQLJ (Driver JCC).
  
  
• Crie seu próximo projeto de desenvolvimento com a versão de teste do software IBM, disponível para download diretamente no developerWorks, ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira o blog Managing the data lifecycle e participe da espaço da comunidade Integrated Data Management, que possui uma lista abrangente de recursos e downloads.
  
  
• Confira o blog do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre os autores

Mario Briggs é líder das ofertas de Open Source para IBM DB2 e IBM Informix, incluindo PHP, Ruby/Rails, Python/Django/SqlAlchemy, Perl e estruturas de acesso a dados Java. Mario tem aproximadamente 11 anos de experiência em desenvolvimento de software e passou vários desses anos nas áreas de acesso a dados, mecanismos relacionais e desempenho de bancos de dados de aplicativos.

Ganesh Choudhary é engenheiro de software de sistemas na Equipe de Software Livre do IBM India Software Labs. Ele trabalha no recurso de ajuste automático do pureQuery para aplicativos Hibernate. Ele possui mestrado em Tecnologia da Informação pelo IIIT, Bangalore.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Visão Geral
• Visão geral do recurso de ajuste automático do pureQuery para Hibernate
• A arquitetura do ajuste automático do pureQuery para Hibernate
• Pré-requisitos para usar o recurso de ajuste automático do pureQuery para Hibernate
• Ativando o recurso de ajuste automático do pureQuery para aplicativos Hibernate
• Executar o aplicativo em Modo de Análise
• Inspecionando o XML de TunedSettings
• Executar o aplicativo com as sugestões de otimização
• Configurando o recurso de ajuste automático do pureQuery para aplicativos Hibernate implementados em um WebSphere Application Server
• Conclusão
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais