Estoy usando Spring + Hibernate para una operación que requiere crear y actualizar literalmente cientos de miles de elementos. Algo como esto:

{
   ...
   Foo foo = fooDAO.get(...);
   for (int i=0; i<500000; i++) {
      Bar bar = barDAO.load(i);
      if (bar.needsModification() && foo.foo()) {
         bar.setWhatever("new whatever");
         barDAO.update(bar);
         // commit here
         Baz baz = new Baz();
         bazDAO.create(baz);
         // if (i % 100 == 0), clear
      }
   }
}

Para protegerme de perder cambios en el medio, los confirmo inmediatamente despuésbarDAO.update(bar):

HibernateTransactionManager transactionManager = ...; // injected by Spring
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus transactionStatus = transactionManager.getTransaction(def);
transactionManager.commit(transactionStatus);

En este punto, tengo que decir que todo el proceso se está ejecutando en una transacción envuelta enorg.springframework.orm.hibernate3.support.ExtendedOpenSessionInViewFilter (Sí, esta es una aplicación web).

Todo esto funciona bien con una excepción: después de unos pocos miles de actualizaciones / confirmaciones, todo el proceso se vuelve muy lento, probablemente debido a que la memoria está hinchada por la cantidad cada vez mayor de objetos guardados por Spring / Hibernate.

En un entorno solo de Hibernate, esto se resolvería fácilmente llamando aorg.hibernate.Session#clear().

Ahora, las preguntas:

¿Cuándo es un buen momento paraclear()? ¿Tiene un gran costo de rendimiento?¿Por qué no son objetos comobar obaz lanzado / GCd automáticamente? ¿Cuál es el punto de mantenerlos en la sesión después de la confirmación (en el siguiente ciclo de iteración no son accesibles de todos modos)? No he realizado un volcado de memoria para probar esto, pero mi buena sensación es que todavía están allí hasta que se salga por completo. Si la respuesta a esto es "Hibernate cache", entonces ¿por qué no se vacía el caché cuando la memoria disponible se está agotando?¿Es seguro / recomendado llamar?org.hibernate.Session#clear() directamente (teniendo en cuenta todo el contexto de Spring, cosas como la carga diferida, etc.)? ¿Hay alguna envoltura / contraparte Spring utilizable para lograr lo mismo?Si la respuesta a la pregunta anterior es verdadera, ¿qué pasará con el objeto?foo, asumiendoclear() se llama dentro del bucle? Y sifoo.foo() es un método de carga diferida?

Gracias por las respuestas.