Manipulando grandes volumes de dados com JPA e Java EE

Assuntos Gerais
#1

Qual a melhor técnica para transferir um grande volume de dados de uma tabela para outra usando JPA no contexto de um servidor de aplicação ? Uma query do JPA eu sei que não é adequada, pois todos os resultados serão alocados na memória. Paginação tem a perda de desempenho por ter que executar várias queries ao invés de executar uma só. Nesse caso, não creio que usar queries nativas JDBC resolvam o problema, pois os problemas de memória e desempenho serão os mesmos (me corrijam se estiver errado). Por fim, cheguei a tentar ScrollableResults do hibernate, que parecia ser a solução ideal. Não pude utilizar, pois creio que o pool de conexões abertas do JBOSS não permite tal operação, obtendo a seguinte exceção:

java.sql.SQLException: Streaming result set com.mysql.jdbc.RowDataDynamic@10a531a is still active. No statements may be issued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming result sets before attempting more queries.

Há sim, essa tarefa de transferência de dados é só uma dentro de uma transação com outras operações envolvidas.

Qualquer orientação é bem válida.
Grato.

#2

Se o problema de utilizar o JPA é o cache, existe um modo de desativar. Agora não me lembro de cabeça, mas tem como.

Por que você não faz um banco comunicar com o outro direto? Crie uma StoredProcedure e uma fará a transferência de dados para outra. [=

#3

Concordo com o Hebert quando fala sobre stored procedures (poderia considerar as queries nativas também).

Desta maneira a execução será feita pelo banco de dados na máquina servidora. Se utilizar o ORM os registro irão trafegar pela rede causando lentidão e grande exploração dos recursos; se o sistema estiver instalado na mesma máquina do banco ainda assim ficaria ruim com o ORM.

flws

#4

Obrigado pelas orientações. Vou tentar queries nativas, pois com stored procedures eu teria a portabilidade entre SGBD’s prejudicada.

#5

[quote=Ruben Lins]Obrigado pelas orientações. Vou tentar queries nativas, pois com stored procedures eu teria a portabilidade entre SGBD’s prejudicada.[/quote]Essa portabilidade é realmente necessária? Com queries nativas você teria o mesmo problema de cache e assim vai…

#6

Bom dia Ruben.
Não entendi para qual finalidade é essa transferência, mas vamos analisar dois cenários.

1.º Cenário
Transferência de dados sem a necessidade das tabelas ficarem 100% do tempo sincronizadas.
Para esse cenário a melhor solução seria usar um insert com select.
Ex:

insert tabela(c1,c2,c3) select c1,c2,c3 from tabela2;

2º Cenário
Transferência de dados com a necessidade das tabelas ficarem 100% do tempo sincronizadas.
Nesse caso a solução adequada seria o uso de “stored procedures”, como foi citada pelo Hebert, mas nesse caso perderia a portabilidade.
Outra solução seria via programação. Mas nesse caso é aconselhável você encontrar um framework que faça isso.

#7

Dependendo do caso, Triggers podem ser interessantes para desacoplar a cópia de dados do sistema, sem a necessidade de chamar nenhuma procedure.

#8