subscripción
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.