implicaciones de escalabilidad de la conversión de beans de sesión sin que POJOs

Question

Imagínese un objeto de servicio usada fuertemente que está implementado como un EJB 2.1 SLSB, y que también pasa a ser thread-safe en sí mismo en virtud de tener ningún estado absoluto. Todos sus métodos públicos son transaccionales (a través de CMT), la mayoría simplemente que requiere una transacción, pero algunos requieren una nueva transacción.

Cuando se modifica esta SLSB a una verdadera Singleton POJO (por ejemplo, utilizando un marco DI), ¿cómo afectará la escalabilidad de la aplicación? Cuando el servicio era un SLSB, el contenedor EJB podría administrar un grupo de instancias de las que cada cliente podría obtener su propia copia, por lo que estoy preguntando si convirtiéndolo en un producto único POJO introducirá algún tipo de contención para que solo caso.

Fwiw, ninguno de los métodos de este servicio son synchronized.

Aclaración: mi motivación para convertir el SLSB a un POJO es la simplicidad tanto de ciclo de vida del objeto (verdadero único versus gestionada por contenedor) y del código en sí mismo (una interfaz y un POJO anotada, en comparación con tres interfaces, una clase de bean, y un montón de XML en ejb-jar.xml).

Además, Fwiw, el servicio en cuestión es un componente de una aplicación web que se ejecuta en un emplazamiento común JBoss 3.x.

Answer 1

Si el POJO es verdaderamente sin estado, o no tiene un estado de conversación (es decir, el estado es inmutable), entonces esto no va a empeorar el rendimiento, e incluso puede mejorar ligeramente ya que realmente está utilizando sólo un ejemplo de su marco DI vez de una piscina desde el recipiente. (Incluso la piscina sufre de contención con una carga elevada.)

No hay sincronización necesaria para un objeto que es seguro para subprocesos por diseño, tal como uno con ninguno o apenas estado inmutable. No habrá contención -. Subprocesos pueden ejecutar libremente métodos en el POJO sin sincronización

Mediante el uso de sólo el POJO también llegar a ver realmente lo que está pasando en su aplicación, y puede estar seguro de que no hay oculto "magia contenedor" pasando detrás de las escenas.

Answer 2

Su POJO parece perfecto.

Así que no, no habrá discordia, su escalabilidad será perfecto.

• No tiene costo adicional.
• Usted puede incluso tener menos porque tiene un caso en lugar de varios
• Su escalabilidad es mejor porque nunca alcanzado el límite de su piscina (que no tiene).