¡Acabo de probar mi aplicación en el generador de perfiles y descubrí que las cadenas sql usan aproximadamente el 30% de mi memoria! Esto es extrañoHibernate produce SQL diferente para cada consulta
Hay muchas cadenas de este tipo almacenadas en la memoria de la aplicación. Se trata de consultas SQL generadas por hibernación, tener en cuenta los diferentes números y guiones bajos se arrastran:
select avatardata0_.Id as Id4305_0_,...... where avatardata0_.Id=? for update
select avatardata0_.Id as Id4347_0_,...... where avatardata0_.Id=? for update
Aquí es la parte que no puedo entender. ¿Por qué hibernate tiene que generar diferentes cadenas sql con diferentes identificadores como "Id4305_0_" para cada consulta? ¿Por qué no puede usar una cadena de consulta para todas las consultas idénticas? ¿Es esto una especie de truco para eludir el caché de consultas?
Agradecería mucho si alguien me describiera por qué sucede y cómo evitar el desperdicio de recursos.
ACTUALIZACIÓN
Ok. Lo encontré. Me equivoqué al asumir la pérdida de memoria, fue mi culpa. Hibernate está funcionando según lo previsto.
Mi aplicación creó 121 (!) SessionFactories en 10 subprocesos, produjeron aproximadamente 2300 instancias de SingleTableEntityPersisters. Y cada SingleTableEntityPersister genera aproximadamente 15 consultas SQL con diferentes identificadores. Hibernate se vio forzado a generar aproximadamente 345,000 consultas SQL diferentes. Todo está bien, nada raro :)
Podría ser útil si se pudiera proporcionar una configuración de asignación simple, el código de prueba y simple DDL tabla que reproduce esta situación. En mi experiencia, nunca he visto a Hibernate crear recuentos de índices de alias de columna tan altos. –
Buen punto. Voy a tratar mañana. :) –
@AndrewFrolov: Espero que mi respuesta se adapte mejor a la pregunta ahora, con sus actualizaciones. En cualquier caso, me alegro de que haya encontrado y solucionado el problema. – ManuPK