ejb - anotacion - Diferencia entre @Stateless y @Singleton

ejb singleton

Question

Estoy siguiendo este tutorial que también usa un EJB:

package exercise1;
import java.util.Random;
import javax.ejb.Stateless;
import javax.inject.Named;
@Stateless
public class MessageServerBean {
private int counter = 0;
public String getMessage(){
Random random = new Random();
random.nextInt(9999999);
int myRandomNumber = random.nextInt();
return "" + myRandomNumber;
}
public int getCounter(){
return counter++;
}
}

Aquí hay un ejemplo de salida:

Hola de facelets
El mensaje es: 84804258
El contador es: 26
Message Server Bean es: exercise1.MessageServerBean@757b6193

Aquí está mi observación:

• Cuando configuro el bean como @Stateless , siempre obtengo la misma ID de objeto y el contador siempre aumenta.
• Cuando configuro el bean como @Stateful , obtengo una nueva instancia cada vez que actualizo la página.
• Cuando lo configuro en @Singleton obtengo los mismos resultados que cuando lo configuré en @Stateless : el mismo ID de objeto, incrementando el contador.

Entonces, lo que realmente me gustaría entender es: ¿cuál es la diferencia entre @Stateless y @Singleton en este caso?

Answer 1

Está viendo la misma salida porque solo hay un cliente que accede al EJB a la vez. El servidor de aplicaciones puede reciclar el mismo objeto EJB sin estado para cada llamada. Si intenta un acceso simultáneo (varios clientes al mismo tiempo) verá aparecer nuevas instancias sin estado.

Tenga en cuenta que, dependiendo de la carga del servidor, ¡incluso dos invocaciones de método consecutivas realizadas por el mismo cliente pueden terminar en diferentes objetos EJB sin estado!

Para un EJB singleton, no habrá diferencia: siempre hay una sola instancia por aplicación, sin importar cuántos clientes intenten acceder a ella.

Answer 2

Según la documentación de Oracle:

Los beans de sesión Singleton ofrecen una funcionalidad similar a los beans de sesión sin estado, pero difieren de ellos en que solo hay un bean de sesión Singleton por aplicación, en lugar de un grupo de beans de sesión sin estado, cualquiera de los cuales puede responder a una solicitud del cliente. Al igual que los beans de sesión sin estado, los beans de sesión singleton pueden implementar puntos finales de servicios web.

Singletons no puede ser pasivado:

Al igual que un bean de sesión sin estado, un bean de sesión singleton nunca se pasiva y tiene solo dos etapas, inexistente y lista para la invocación de métodos de negocio (...)

La documentación explica cuándo usar cada tipo de bean , y los beans Singleton tienen lo siguiente:

Un único enterprise bean debe ser accedido por múltiples hilos al mismo tiempo.

La aplicación necesita un bean empresarial para realizar tareas en el inicio y cierre de la aplicación.

Entonces, para su ejemplo, no hay diferencia entre las dos anotaciones.