0

What are the benefits in having a bunch of pooled "stateless instances" instead of one "stateless singleton bean" in Java-EE?

Singleton Java-EE:

@ApplicationScoped
public class MySingletonDAO {
// no global properties are shared
..
}

or an alternative stateless singleton bean:

@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class MySingletonDAO {
// no global properties are shared
..
}

Stateless Java-EE:

@Stateless
public class MyStatelessDAO {
..
}

I cannot see any benefit in using a @Stateless-bean instead of a "stateless singleton"-bean. Are there any?

nimo23
  • 5,170
  • 10
  • 46
  • 75
  • possible related to https://stackoverflow.com/questions/14464823/difference-between-stateless-and-singleton – second Jul 28 '19 at 21:31
  • @second I have red this and I cannot find any information why choosing Stateless instead of "stateless singleton". So it's only little related to this issue. – nimo23 Jul 28 '19 at 21:38
  • The concurrent usage should be a benefit, but you were probably aware of that already as you described it as a `bunch of pooled` objects. – second Jul 28 '19 at 21:46
  • "The concurrent usage" of stateless-bean is not a benefit because "(stateless) singletons" can also be accessed concurrently. – nimo23 Jul 28 '19 at 21:56
  • Sure, but in case you do some (albeit whacky) synchronisation there it won`t run as nicely. An example for that might be a global counting mechanism that is split across multiple instances. – second Jul 28 '19 at 22:02
  • "global counting mechanism that is split across multiple instances" ? Such cases are better done with `@javax.ejb.Singleton @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)` instead of `@Stateless`. – nimo23 Jul 28 '19 at 22:07

0 Answers0