subscripción
Y si hablamos de...
… pools y caches
Agosto 15th, 2003 - [Enlace local]
aunque ya me ha pasado más veces, los comentarios de �lvaro a mi post sobre el front controller me ha recordado la aparente confusión que hay entre los conceptos de pool y cache en la informática.
Bien, pongamos un ejemplo en cristiano. Supongamos que mi empresa tiene una biblioteca interna en la primera planta, y que yo trabajo en la décima. Y supongamos que tienen dos volúmenes de cada libro. Esta biblioteca serÃa un pool de objetos, puesto que puedes coger los libros pero después tienes que devolverlos para que otro los utilice (el hecho de que haya varios libros no juega ningún rol en este caso). Cojo un libro, lo leo, lo devuelvo. Listo. Si el libro que quiero esta ya prestado, o me quedo esperando, o la librerÃa compra una nueva edición (pool extensible), etc.
Como implemente aquà una cache?. Bien, si toda la gente que trabaja con Java esta en mi planta, porque no poner una habitación en la décima planta con los libros sobre java?. Asà no tendremos que ir al primer piso y volveremos más rápido al trabajo. Pero que pasa si no me entran en esa habitacion todos los libros sobre java?, que tendre únicamente los que se usan más a menudo. Si alguién quiere uno que no se encuentra en esta habitación tendremos que devolver uno a la biblioteca principal para poder dejar allà el nuevo.
En informática... bien, se suele hacer una pool de objetos que se quieren reutilzar, normalmente porque nos ha costado mucho crearlos o por su simpleza en cuanto a complejidad de ejecución (como conexiones con sockets, EJB SLSB, etc.). Sin embargo queremos hacer una cache de datos que usamos mucho, o que preveemos que se van a volver a utilizar en breve (como los diez últimos post en un foro, Entity Beans) para evitar volver a cargarlos.
posiblemetne sean malos ejemplos, estoy seguro, pero esumiendo se podrÃa decir: una pool hace que reciclemos, una cache hace que trabajemos menos.
» Leer más, comentarios, etc...
Y si hablamos de...
… Cáñamo
Agosto 14th, 2003 - [Enlace local]
Casà todo el mundo que ha pasado por javaHispano me ha oido hablar alguna vez sobre Cáñamo (lo siento por la web de aspecto semi-abandonado, estamos remodelándola, pero el desarrollo sigue). Bien, ahora lo vuelvo a hacer. Sorry.
Para los que no lo sepais, decir que Cáñamo (licencia BSD), más que un framework para aplicaicones web, es algo asà como un mini servidor de aplicaciones para aplicaciones web (aplicaciones que sigan unas normas, claro). Es decir, se parece más al núcleo de *Nuke (aunque mejorado) que a Struts (aunque ahora con los modulos de Struts se parezca más), aunque por supuesto, para que puedan ser ejecutadas por el motor tienen que seguir ciertas normas. Ahora mismo hay varias aplicaciones GPL para disponibles (catálogo de elementos para noticias y otros, artÃculos, foros, anillo de webs, etc.) de las que puede haber N instancias ejecutándose simultaneamente en una instancia (ejemplo: catálogo para noticias y también para listado de productos). Un ejemplo vivo de lo que se puede hacer con Cáñamo es javaHispano.
¿A que viene esto?. Simplemente a invitaros a participar en su desarrollo. Ahora es un buen momento, tres personas (y media) estan participando activamente en su desarrollo, una empresa (NHT-Norwick) esta usándolo y participando en el mantenimiento de su núcleo BSD, etc. Hay varias personas iniciándose con él, de modo que empezar varios a la vez puede resultar más sencillo.
Vale... ¿qué en la web no hay documentación?, cógela (de momento, ya he dicho que estamos de remodelación en la web) del CVS (módulo docs), encontrarás, como poco, la guÃa de instalación, la teorÃa de la guÃa del desarrollador y la práctica de la misma, creando el necesario hola mundo. Y por supuesto las listas de distribución.
Bien... ¿qué para que esto arranque necesitamos que más gente lo instale?, cierto, estas invitado a hacerlo. Obviamente tenemos que hacerlo accesible más fácilmente (trabajamos en ello!), pero el caso es que en de todos modos obtenerlo desde el CVS no deberÃa ser un problema para nadie en estos dÃas. Trabajamos también en hacer disponibles aplicaciones preconfiguradas (foros, portal, etc). Mucho que hacer.
Y todo esto.. ¿para qué?, ¿por qué dedicarle tu tiempo?.
- Primero, por hacer algo interesante, con gente interesante.
- Segundo por aprender, o por enseñar, o por mejorar, o discutir, lo que quieras.
- Opensource (aunque no es obligatorio). Lo que hagas podrán disfrutarlo todos, algo útil.
- Y por último, por javaHispano, si estas leyendo esto supongo que conoceras la web, y espero que quieras participar dentro de ella.
» Leer más, comentarios, etc...
Y si hablamos de...
… sobre el front controller
Agosto 14th, 2003 - [Enlace local]
Akuma ha hecho un curso sobre J2EE, y aunque no quedó del todo satisfecho, como resultado se ha puesto a jugar con el patrón front controller para aplicaciones web (El patrón front controller).
Le comenté el tema de no instanciar una acción para cada petición, y aunque reconoció no entenderlo del todo, lo implementó (Revisado: el patrón front controller). De aquà mi tirón de orejas por creerse las cosas a la ligera, aunque vengan de alguién tan convincente como yo ;-).
Ya que la explicación es un poco larga, pues le robo el post :-).
Antes de nada, supongo que habrÃa claro por qué no queremos andar crendo instancias por cada petición. Bueno, pues no queremos porque andar creando esas instancias es una labor costosa (además por reflection), una labor que si bien ahora mismo podemos considerar requiere un tiempo despreciable es un tiempo que nos podemos ahorrar. Tened en cuenta que en una web más o menos grande (por ejemplo javaHispano, con entre 50 y 100 usuarios concurentes normalmente) podemos estar generando un montón de acciones.
Un entorno web es un entorno concurrente por definición, solucionado en Java en base a hilos, hasta aquà sin problemas. Entonces ¿por qué podemos permitirnos mantener una única instancia de una acción para servir todas las peticiones?. Bien, pues podemos, si y solo sÃ, solo accedemos a valores propios del hilo, en este caso, valores de la request, valores de la sesión y variables definidas en los métodos. Que la request y la sessión son propias de cada petición esta claro, sobre los métodos quizás no.
Las variables definidas en un método solo viven dentro de ese método, se crean con el método y se destruyen con el método. Es por eso que, mientras nuestras acciones solo utilizen para escritura (para lectura peuden usar variables de instancia) variables de ese tipo, no tendremos problema alguno de concurrencia, cada hilo tendrá las suyas propias.
¿Cual es el problema de esta aproximación?. Que puede invitar al programador (al menos si consigues hacer un framework de éxito) a olvidarse de posibles problemas de concurrencia y que acabe metiendo la pata. ¿Cuando puede ocurrir esto?: cuando te sales del método de ejecución para tratar algunas variables de instancia (datos cacheados y datos de configuración de la acción principalmente, aunque no únicamente), donde si que tendrás que usar la sincronización si piensas cambiar dichos valores.
En todo caso, aún no penseis que la implementación de Akuma es perfecta, más información la encontrareis como comentarios en su post.