La historia del que confiaba ciegamente en Hibernate
¡Hola!, hoy es un día especial porque acabo de publicar en "El Camino de Java, Volumen 2", las primeras lecciones de la nueva sección "Hibernate". Si desconoces para qué sirve esta librería, te invito a ver el video que publiqué en java.aid2do.com y en mi canal de YouTube.
Hibernate te ayuda a realizar las consultas a la base de datos utilizando solamente objetos. Es una librería muy eficiente, pero debes tener cuidado porque usar Hibernate no significa que tu sistema será mágicamente más rápido, como me sucedió cuando conocí al programador que confiaba ciegamente en Hibernate; te voy a contar la historia:
Resulta que se estaba desarrollando un nuevo sistema para una compañía, pero además de que estaban sufriendo de retrasos en los tiempos de entrega, los usuarios durante la fase de prueba habían encontrado que funcionaba más lento que una tortuga, y el equipo de desarrollo argumentaba que el problema estaba en el hardware porque se estaban aplicando "las mejores técnicas de programación recomendadas y aplicadas en la industria", así que me llamaron para que le echara un vistazo al sistema y después de comprobar que efectivamente era un problema de hardware, entonces autorizarían la compra de mejor equipo de cómputo.
Me entrevisté con uno de los programadores del sistema para que me hiciera un "tour" del código y no tardé mucho en descubrir por qué funcionaba tan lento. Entre los detalles que encontré, lo que me llamó la atención fue que estaban utilizando Hibernate, pero lo estaban haciendo de tal manera que no solo no ayudaba, sino que contribuía a que el resultado fuera lento e inestable.
Para que te des una idea, como se trataba de una página web, una de sus pantallas era la lista de registros de alguna tabla, y para consultar lo hacían de esta manera: Primero, ejecutaban una consulta para saber cuántos registros había en la tabla, con eso creaban un arreglo y después ejecutaban otra consulta para obtener solamente las llaves primarias de los registros que iban a mostrar y guardarlas en el arreglo, finalmente recorrían el arreglo y en cada iteración ejecutaban una consulta para obtener la información del registro correspondiente, y toda la información se guardaba en memoria para mostrarla al usuario, a pesar de que solo una fracción se mostraba en pantalla, pero por si fuera poco, para cada operación que mencioné, abrían y cerraban la conexión, incluso al momento de recorrer los registros que se iban a mostrar, en cada iteración se abría conexión, se leía el registro y se volvía a cerrar la conexión. Eso no solo era lento, sino que el consumo de memoria era tal, que si más de un usuario consultaba la página al mismo tiempo, pues el servidor se quedaba sin memoria y el sistema fallaba para todos, y por supuesto antes de quedarse sin memoria, se hacía extremadamente lento porque Java dedicaba todo el tiempo del procesador a intentar encontrar la forma de liberarla.
Acto seguido hablé con el programador para informarle lo que había encontrado y me sorprendió su respuesta:
Al menos sus argumentos tenían fundamento, y te voy a explicar unos conceptos en caso que no estés familiarizado: El "pool de conexiones" es una técnica donde se mantienen abiertas un conjunto de conexiones a la base de datos y en caso de necesitarse, se reutilizan para evitar el costo de abrirlas y cerrarlas constantemente, y por otro lado el "caché" es un componente que mantiene en memoria la información de uso frecuente para evitar tener que leerla del disco que sería una operación más lenta.
Así que su respuesta me dejó pensando, no porque estuviera en lo correcto, sino porque me di cuenta de hasta qué grado creía ciegamente en una librería, y también me llamó la atención el cómo estaba convencido de que bastaba con aplicar mejores prácticas para obtener el mejor resultado. No hacía falta comprobar las teorías ni razonar técnicas de programación, ¡eran prácticas aceptadas!.
Después que le mostré cómo todo lo que estaba haciendo se podía realizar con una sola conexión a la base de datos, una sola consulta, y el resultado era miles de veces más rápido, se quedó mudo.
Así que la moraleja de la historia es: Aunque existen librerías muy útiles para hacer ciertas cosas, eso no significa que sean la solución para cualquier problema, y por otro lado, aunque con el tiempo se han creado mejores prácticas de programación, eso tampoco significa que aplicándolas sin razonar vas a obtener siempre el mejor resultado.
Si estás aprendiendo con un curso que solo te muestra los pasos a seguir, pues buena suerte, pero si quieres aprender Java con un curso enfocado en razonar antes que en memorizar, entonces inscríbete a "El Camino de Java"...
¡Hasta la próxima!
Raúl Cosío