Abriendo un paréntesis, algunos pueden confundirse con un concepto similar pero a su vez diferente: Pool de Objetos. Ambos, "cacheo" y "pooleo" son usados para un mismo propósito general, mejorar el rendimiento al reducir el costo de crear ciertos objetos que consumen recursos vitales (tiempo, ancho de banda, memoria, etc).
La diferencia principal es que el pool de objectos no requiere "unicidad" de los objetos que son almacenados. En otras palabras, para cierta necesidad, cualquier objeto guardado en el pool puede hacer el trabajo. De esta manera el pool puede balancear las solicitudes para cierto objeto al mantener varias instancias para devolverlos de manera inmediata. Cache por contraste requiere que un objeto sea mapeable, esto es que pueda ser identificado por una llave única (esta llave puede ser una llave compuesta como veremos después en los siguientes posts). Para este caso, cualquier objeto no puede hacer el trabajo, se necesita un objeto especifico y debemos poder tener la facultad de contruit la llave para el almacenamiento y recuperación del objeto.
Para ejemplificar esto podemos pensar en una aplicación hipotética que trabaje con instancias de una clase llamada "Persona". Supongamos que un proceso de negocio requiere obtener una persona, cualquier persona de manera aleatoria. Debido a que el proceso para construir a la persona requiere de varios llamados a una base de datos, un pool es implementado de manera que cierto número de instancias de la clase Persona son mantenidas in memoria local. La aplicación por tanto haría un llamado similar a esto:
La diferencia principal es que el pool de objectos no requiere "unicidad" de los objetos que son almacenados. En otras palabras, para cierta necesidad, cualquier objeto guardado en el pool puede hacer el trabajo. De esta manera el pool puede balancear las solicitudes para cierto objeto al mantener varias instancias para devolverlos de manera inmediata. Cache por contraste requiere que un objeto sea mapeable, esto es que pueda ser identificado por una llave única (esta llave puede ser una llave compuesta como veremos después en los siguientes posts). Para este caso, cualquier objeto no puede hacer el trabajo, se necesita un objeto especifico y debemos poder tener la facultad de contruit la llave para el almacenamiento y recuperación del objeto.
Para ejemplificar esto podemos pensar en una aplicación hipotética que trabaje con instancias de una clase llamada "Persona". Supongamos que un proceso de negocio requiere obtener una persona, cualquier persona de manera aleatoria. Debido a que el proceso para construir a la persona requiere de varios llamados a una base de datos, un pool es implementado de manera que cierto número de instancias de la clase Persona son mantenidas in memoria local. La aplicación por tanto haría un llamado similar a esto:
PersonaPool.solicitarPersona();
Ahora si otro proceso requiere obtener una persona en especifico identificable por un ID, requieriendo tambi[en hacer una serie de llamados a la base de datos para la construcci[on del objeto, un diseño de cache seria necesario para evitar el alto costo de realizar todos estos llamados a la base de datos. La aplicación por tanto haría un llamado como este:
PersonaCache.obtenerPersona('125677');
El pool de objetos es una técnica usada ampliamente en aplicaciones que requieren abrir conexiones con una base de datos a traves de objetos de conexión. No obstante debemos tener siempre la mente abierta para aprovechar cualquier buena oportunidad para usarla en nuestras aplicaciones.
