Singleton EJB vs CDI @ApplicationScoped
Reemplaza los Singleton EJBs por beans CDI @ApplicationScoped para una gestión de estado compartido más simple.
@Singleton
@Startup
@ConcurrencyManagement(
ConcurrencyManagementType.CONTAINER)
public class ConfigCache {
private Map<String, String> cache;
@PostConstruct
public void load() {
cache = loadFromDatabase();
}
@Lock(LockType.READ)
public String get(String key) {
return cache.get(key);
}
@Lock(LockType.WRITE)
public void refresh() {
cache = loadFromDatabase();
}
}
@ApplicationScoped
public class ConfigCache {
private volatile Map<String, String> cache;
@PostConstruct
public void load() {
cache = loadFromDatabase();
}
public String get(String key) {
return cache.get(key);
}
public void refresh() {
cache = loadFromDatabase();
}
}
Menos ruido de anotaciones
Sin @ConcurrencyManagement, @Lock ni @Startup — solo una única anotación @ApplicationScoped.
Concurrencia flexible
Usa locks de java.util.concurrent o volatile para exactamente la seguridad de hilos que necesitas.
Pruebas sencillas
Los beans CDI simples se pueden instanciar directamente en pruebas sin un contenedor EJB.
Ampliamente disponible desde Jakarta EE 8 / Java 11
Los Singleton EJBs agrupan la gestión de concurrencia (@Lock, @ConcurrencyManagement) y la inicialización temprana (@Startup) en el contenedor EJB. Un bean CDI @ApplicationScoped logra el mismo ciclo de vida de instancia única con mucha menos ceremonia. Cuando se necesita control de concurrencia, las utilidades estándar de java.util.concurrent ofrecen un control más granular que las anotaciones de bloqueo de EJB.