Singleton EJB kontra CDI @ApplicationScoped
Zastąp Singleton EJB beanami CDI @ApplicationScoped dla prostszego zarządzania stanem współdzielonym.
@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();
}
}
Mniej szumu adnotacji
Brak @ConcurrencyManagement, @Lock ani @Startup — tylko jedna adnotacja @ApplicationScoped.
Elastyczna współbieżność
Używaj blokad java.util.concurrent lub volatile dla dokładnie potrzebnego bezpieczeństwa wątków.
Łatwe testowanie
Zwykłe beany CDI można instancjonować bezpośrednio w testach bez kontenera EJB.
Szeroko dostępne od Jakarta EE 8 / Java 11
Singleton EJB łączą zarządzanie współbieżnością (@Lock, @ConcurrencyManagement) i chętną inicjalizację (@Startup) z kontenerem EJB. Bean CDI @ApplicationScoped osiąga ten sam cykl życia z jedną instancją ze znacznie mniejszą ceremonią. Gdy potrzebna jest kontrola współbieżności, standardowe narzędzia java.util.concurrent dają bardziej szczegółową kontrolę niż adnotacje blokad EJB.