2

Imagine a heavily-used service object that's implemented as an EJB 2.1 SLSB, and that also happens to be thread-safe in itself by virtue of having no state whatsoever. All its public methods are transactional (via CMT), most simply requiring a transaction, but some requiring a new transaction.

If I convert this SLSB to a genuine singleton POJO (e.g. using a DI framework), how will that affect the scalability of the application? When the service was a SLSB, the EJB container would manage a pool of instances from which each client would get its own copy, so I'm wondering whether turning it into a singleton POJO will introduce some kind of contention for that single instance.

FWIW, none of this service's methods are synchronized.

Clarification: my motivation for converting the SLSB to a POJO is simplicity of both the object's lifecycle (true singleton versus container-managed) and of the code itself (one interface and one annotated POJO, versus three interfaces, one bean class, and a bunch of XML in ejb-jar.xml).

Also, FWIW, the service in question is one component of a collocated web app running on JBoss 3.x.

Andrew Swan
  • 13,427
  • 22
  • 69
  • 98
  • This answer: http://stackoverflow.com/questions/134791/why-pool-stateless-session-beans/135840#135840 claims there would be "a lot of contention and blocking", but there's no corroboration, citation, or even up-voting of that statement, so I don't know how much weight to give it (no offence to Mwanji intended). – Andrew Swan Oct 09 '09 at 05:45
  • Can you elaborate on your environment? Are you still using a Java EE server? Are you running on one box or many? How many cores per box? And why do you need a singleton POJO as opposed to many operating in different threads? – Jim Ferrans Oct 09 '09 at 06:30
  • @Jim: I've updated the question. But your comment seems to imply that a singleton couldn't service multiple threads - is this really the case? This gets to the heart of my question; how will using one POJO compare in scalability terms to using a pooled SLSB? Will some threads have to wait to use the POJO until others have finished? – Andrew Swan Oct 16 '09 at 21:06
  • Yes, FWIW. I've updated the question accordingly. – Andrew Swan Jul 12 '10 at 04:14

2 Answers2

3

If the POJO is truly stateless, or has no conversational state (i.e. state is immutable) then this will not worsen the performance, and may even improve slightly since you really are using just one instance from your DI framework rather than a pool from the container. (Even the pool suffers from contention under high load.)

There is no synchronization needed for an object that is thread-safe by design, such as one with none or just immutable state. There will be no contention - threads can freely execute methods on the POJO without synchronization.

By using just the POJO you also get to see really what is going on in your app, and can be sure there is no hidden "container magic" going on behind the scenes.

mdma
  • 56,943
  • 12
  • 94
  • 128
1

Your POJO seem perfect.

So No, there will be no contention, your scalability will be perfect.

  • You have no additional cost.
  • You even have less because you have one instance instead of several
  • Your scalability is better because you will never hit the limit of your pool (you don't have).
KLE
  • 23,689
  • 4
  • 56
  • 62