OutOfMemory e Corrupção de Banco de Dados

eu tambem tenho nisso numa aplicacao. se eu deixar 20 dias sem reiniciar, da OOm e o MALDITO tomcat loga o Error e ENGOLE. sendo que na documentacao esta BEM explicitado que voce nao deve segurar a execucacao ao ocorrer um OOM.

voce deve dar um jeito de nao engulir a OOM, no primeiro momento que ela ocorrer ela deve subir e em algum lugar voce desliga a aplicacao.

use um pofiler pra saber o que voce esta segurando que nao era pra segurar.

Voce deveria focar em resolver o OOM primeiro, ao inves de focar nos problemas de dados corrompidos.
Talvez uma coisa nem esteja associada a outra, mas resolver o OOM deveria ser a sua prioridade.

Rafael

Isso é teoricamente possivel de acontecer dependendo da qualidade do driver o comportamento padrão do banco no caso de transações interrompidas sem commit/rollback.

O driver pro teu banco pode estar fazendo burradas quando um OOM acontece dentro dele, procure no google a respeito.

Ou então pode estar ocorrendo da transação estar sendo interrompida antes do commit/rollback e o teu RDBMS estar dando commit para você.

Cenario:

1. begin trs
2. update xxx
    insert xxx
2.1. A JVM é terminada 
3. ok ? commit else rollback

Fora isso não posso sugerir muito mais sem maiores informações sobre o ambiente.

Se não tiver outra maneira, faça o seguinte:

try {
  commited = false;
  ....
  commit();
  commited = true;
} catch(OutOfMemoryError e) {
  doMemHedge();
} finally {
   if(!commited) rollback();
}

static byte[] hedge = new byte[1000 * 100];
void doMemHedge() {
  hedge = null;
  System.gc();
}

Esse exemplo simplifica bastante a coisa por que não leva em conta a reaquisição de memoria de hedging nem JVMs que usam areas distintas para tamanhos diferentes de objetos.

Parceiro,

minha aplicação é feita com (Spring + Hibernate + Oracle) também.
No ambiente do cliente ocorre muito outOfMemory, porém nunca houve problema de corrupção de dados ou falha no controle de transação.