A la vista de suficientes ojos, todos los errores resultan evidentes.
Los servidores de aplicaciones y la arquitectura J2EE fue diseñada desde el principio con el multithreading en mente. La idea de escalabilidad y procesamiento paralelo de forma segura ha sido en una constante en su desarrollo y evolución para que los desarrolladores pudiéramos construir aplicaciones seguras sin preocuparnos de asuntos como la gestión de memoria o la sincronización de objetos.
Sin embargo, para las aplicaciones "de la vida real" nos encontramos con que algunas veces tenemos que "
serializar" (en el sentido de alinear poniendo en serie, encolar manteniendo un orden y como contraposición al procesamiento paralelo) llamadas o procesamientos concretos... Algo para lo que J2EE no fue pensado desde el principio. Así, en el diseño y construcción de aplicaciones empresariales se suelen dar una serie de necesidades relacionadas entre si que, hasta hace poco, no han tenido solución directa manejada en el estándar JEE:
- Serialización o sincronización de procesamiento de peticiones de un webservice. Es decir, poder hacer un WebService como si fuese un Servlet SingleThreadModel (ya obsoleto, por cierto). En definitiva: garantizar que no se atiende otra petición mientras se está atendiendo ya una, evitando la simultaneidad y por tanto evitando también duplicidad de procesamientos realizada por un cliente demasiado impaciente.
- Serialización o proceso ordenado de los mensajes de una cola JMS o, lo que es lo mismo, mantenimiento del orden de llegada en el procesamiento de los mensajes. Esto, que podría parecer obvio, no lo es tanto, ya que para un MDB (Message Driven Bean), el contenedor crea un pool de objetos que trabajan en paralelo de forma que si se sacan 2 o 4 mensajes simultáneamente, puede ser que un mensaje más reciente se tarde menos en procesar que un mensaje anterior.
- Instanciación de un singleton, patrón en principio no permitido por la especificación J2EE (hasta la reciente EJB 3.1, de la que hablaré más adelante). El patrón singleton es tremendamente necesario para asegurar la instanciación única de motores o manejadores de objetos (conexiones, datos, cachés, clientes, etc) que deben estar perfectamente sincronizados.
El que no haya tenido que solucionar este problema podrá pensar que nada más fácil como especificar al servidor que instancie un pool de tamaño 1 para el EJB/MDB que queramos y,
voilà, problema solucionado. La idea es buena. Si aseguramos una y sólo una exclusiva y única instancia de nuestro EJB, podemos resolver las tres necesidades de un sólo plumazo: podríamos publicar dicho EJB como un Webservice, tener un sólo MDB o tener nuestro Singleton.... Por ejemplo, en el caso de Glassfish, podríamos indicarlo en el correspondiente fichero sun-ejb-jar.xml, de la siguiente forma:
DataProviderService
1
1
1
0
Pero lamentablemente no es así:
no funciona. Al menos en Weblogic, Glassfish y JBoss. Dudo que eso sea posible en ninguno. La razón es sencilla: el contenedor no está diseñado para eso, sino justamente para lo contrario, con lo que conseguiremos un nivel altísimo de reciclado de instancias, pero no conseguiremos mantener la misma instancia de forma permanente sin que la recicle el servidor. Tampoco haciendo variaciones con esos parámetros. Tras un número suficiente de pruebas comprobaremos que el servidor recicla y mantiene, aunque sea durante pocos instantes, varias instancias del mismo EJB.
Las soluciones
En principio hay tres soluciones válidas.
Si estás usando JEE 5 o inferior, es decir, un contenedor EJB 3.0 o inferior, tienes dos soluciones a tu alcance que básicamente pasan por mantener la sincronización
fuera del servidor de aplicaciones: crear un JMX MBean o sincronizar por tu cuenta. Si estás usando JEE 6, estás de enhorabuena. Aquí están mis propuestas.
Usar un MBean de JMX
Un MBean es, en definitiva, un singleton accesible vía JMX. No es un objeto manejado por el contenedor de EJB ni un estándar JEE, pero es una solución más elegante que realizar un Singleton por código ya que podemos controlar su ciclo de vida e incluso acceder a su estado de manera remota. Eso si, como decía, la sincronización de los objetos que use (colas JMS, etc) corre por nuestra cuenta. El problema del WebService lo podemos reducir a un problema de JMS, ya que podríamos publicar los mensajes en una cola y extraerlos uno a uno haciendo que nuestro MBean sea un cliente JMS.
Usar un recurso sincronizable
Un mismo EJB puede ejecutarse en diferentes JVM's. El ciclo de vida de los objetos y su concurrencia es cosa del contenedor. Por tanto, declarar un método de un EJB como "synchronized" es una violación de la especificación y no debería ser una opción. Por tanto, nuestros EJB's deberán usar un objeto manejado que pueda ser sincronizado: bien un Singleton propio (si nos basta con sincronizar para una única JVM), bien usando la transacciones serializables de base de datos (si necesitamos sincronizar entre varias JVM's o queremos hacerlo más escalable).
Crear un Singleton Session Bean
Si puedes usar un contenedor JEE 6 compatible, puedes implementar un
Singleton Session Bean. Ésta es por fin la solución adecuada dentro del estándar JEE: un singleton manejado con atributos para controlar la sincronización. Con este método se solucionan de un plumazo todas las cuestiones de sincronización o singletons de una forma segura y manejada por parte del contenedor EJB.
Referencias y más información:
