Considerações sobre a Programação do Utilitário de Carga do JPA

Um Utilitário de Carga do Java Persistence API (JPA) é uma implementação do plug-in do utilitário de carga que usa o JPA para interagir com o banco de dados. Use as seguintes considerações ao desenvolver um aplicativo que usa um utilitário de carga do JPA.

Entidade eXtreme Scale e Entidade do JPA

É possível designar qualquer classe POJO como uma entidade eXtreme Scale usando as anotações de entidade eXtreme Scale, uma configuração XML ou ambos. Também é possível designar a mesma classe POJO como uma entidade do JPA utilizando anotações de entidades JPA, a configuração XML ou ambas.

Entidade eXtreme Scale : Uma entidade eXtreme Scale representa dados persistentes que são armazenados em mapas ObjectGrid. Um objeto de entidade é transformado em uma tupla de chave e em uma tupla de valor, que então são armazenadas como pares chave-valor nos mapas. Uma tupla é uma matriz de atributos primitivos.

Entidade do JPA: Uma entidade do JPA representa dados persistentes que são armazenados em um banco de dados relacional automaticamente usando uma persistência gerenciada por contêiner. Os dados são persistidos em algum tipo sistema de armazenamento de dados no formato apropriado, como tuplas de banco de dados em um banco de dados.

Quando uma entidade do eXtreme Scale é persistida, suas relações serão armazenadas em outros mapas de entidade. Por exemplo, se você estiver persistindo uma entidade Consumer com uma relação de um para muitos em uma entidade ShippingAddress, se a persistência em cascata for ativada, a entidade ShippingAddress será armazenada no mapa shippingAddress em formato de tupla. Se você estiver persistindo uma entidade JPA, as entidades do JPA relacionadas também serão persistidas para as tabelas de banco de dados se a persistência em cascata estiver ativada. Quando uma classe POJO é designada como entidade do eXtreme Scale e entidade do JPA, os dados podem ser persistidos para os mapas e bancos de dados da entidade ObjectGrid. Os usos comuns são:
  • Cenário de Pré-Carregamento: Uma entidade é carregada de um banco de dados usando um provedor do JPA e é persistida nos mapas de entidade do ObjectGrid.
  • Cenário do Utilitário de Carga: Uma implementação do Utilitário de Carga é conectada aos mapas de entidade ObjectGrid para que uma entidade armazenada nos mapas de entidade ObjectGrid possa ser persistida ou carregada a partir de um banco de dados usando provedores do JPA.

Também é comum que uma classe POJO seja designada apenas como uma entidade JPA. Neste caso, o que é armazenado nos mapas do ObjectGrid são as instâncias do POJO, versus as tuplas de entidade no caso da entidade do ObjectGrid.

Considerações de Design do Aplicativo para Mapas de Entidade

Ao conectar uma instância do JPALoader, as instâncias de objeto serão diretamente armazenadas nos mapas do ObjectGrid.

Porém, ao conectar a um JPAEntityLoader, a classe de entidade é designada como uma entidade do eXtreme Scale e uma entidade do JPA. Neste caso, trate esta entidade como se ela tivesse dois armazenamentos de persistência: os mapas de entidade do ObjectGrid e o armazenamento de persistência do JPA. A arquitetura torna-se mais complicado do que o caso do JPALoader.

Para obter mais informações sobre o plug-in JPAEntityLoader e considerações sobre o design de aplicativo, consulte o Plug-in JPAEntityLoader. Essas informações também podem ajudar se você planejar implementar seu próprio utilitário de carga para os mapas de entidade.

Considerações sobre Desempenho

Certifique-se de configurar o tipo de busca ávido ou lento adequado para os relacionamentos. Por exemplo, um relacionamento um-para-muitos bidirecional de Consumer com ShippingAddress, com o OpenJPA para ajudar a explicar as diferenças de desempenho. Neste exemplo, uma consulta JPA tenta select o from Consumer o where . . . efetuar um carregamento em massa e também carregar todos os objetos ShippingAddress relacionados. Um relacionamento um para muitos definido na classe Consumer é o seguinte:

@Entity
public class Consumer implements Serializable {

    @OneToMany(mappedBy="consumer",cascade=CascadeType.ALL, fetch =FetchType.EAGER) 
    ArrayList <ShippingAddress> addresses;

A seguir há o consumidor da relação muitos-para-um definido na classe do ShippingAddress:

@Entity
public class ShippingAddress implements Serializable{

    @ManyToOne(fetch=FetchType.EAGER)
    Consumer consumer;
}

Se os tipos de busca de ambos os relacionamentos estiverem configurados como ávido, o OpenJPA utilizará consultas N+1+1 para obter todos os objetos Consumer e objetos ShippingAddress, em que N é o número de objetos ShippingAddress. Entretanto, se ShippingAddress for alterado para utilizar o tipo de busca lento conforme a seguir, ele fará apenas duas consultas para obter todos os dados.

@Entity
public class ShippingAddress implements Serializable{

    @ManyToOne(fetch=FetchType.LAZY)
    Consumer consumer;
}

Embora a consulta retorne os mesmos resultados, ter um número baixo de consultas diminui significativamente a interação com o banco de dados, o que pode aumentar o desempenho do aplicativo.