0

I've been googling and I just realized something really odd (at least to me). apparently it's recommended to set spring objects as singletons. I have several questions:

  1. logically, it would affect performance right? if 100 users (total exaggeration) are using the same @service objects, wouldn't that mean the other 99 must queue in line to get that @service? (thus, performance issue)
  2. what if by some diabolical design, those spring objects have states (synchronization problem)? This usually happens with ORM since the BaseDAOImpl usually have protected injected sessionfactory
  3. speaking of injected sessionfactory, I thought annotations are not inherited? could somebody give explanation about this? thanks
user3268357
  • 1
  • Perhaps if you provide some context of the recommendation? I would find it hard to believe that there is a single recommendation for all scenarios... – EdH Feb 04 '14 at 04:06
  • The `singleton` scope of the bean doesnt mean it cannot be accessed by parallel threads. `Singleton scope != synchronized` – Hrishikesh Feb 05 '14 at 07:54

2 Answers2

3

apparently it's recommended to set spring objects as singletons.

It's not necessarily recommended, but it is the default.

logically, it would affect performance right? if 100 users (total exaggeration) are using the same @service objects, wouldn't that mean the other 99 must queue in line to get that @service? (thus, performance issue)

First of all, forget about users. Think about objects, threads, and object monitors. A thread will block and wait if it tries to acquire an object monitor that is owned by another thread. This is the basis of Java's synchronization concept. You use synchronization to achieve mutual exclusion from a critical section of code.

If your bean is stateless, which a @Service bean probably should be (just like a @Controller beans), then there is no critical section. No object is shared between threads using the same @Service bean. As such, there are no synchronized blocks involved and no thread waits on any other thread. There wouldn't be any performance degradation.

what if by some diabolical design, those spring objects have states (synchronization problem)? This usually happens with ORM since the BaseDAOImpl usually have protected injected sessionfactory

A typical design would have you use SessionFactory#getCurrentSession() which returns a Session bound to thread, using ThreadLocal. So again, these libraries are well written. There's almost always a way with which you can avoid any concurrency issue, either through ThreadLocal design as above or by playing with bean scopes.

If you can't, you should write your code so that the bottleneck is as small as possible, ie. just the critical section.

speaking of injected sessionfactory, I thought annotations are not inherited? could somebody give explanation about this?

I'm not sure what you mean with this. You are correct that annotations are not inherited (but methods are inherited with their annotations). But that might not apply to the situation you are asking about, so please clarify.

Community
  • 1
  • 1
Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
0

  1. service object being singleton doesnt mean that it has synchronised access. multple users can invoke it simultaneouly. Like a single servlet instance is used by many concurrent users in a webapplication. You only need to ensure that there is no state in your singleton object.

  2. SessionFactory is a threaf safe object as its immutable, session is not thread safe. Ad since session factory is a heavy object, its recommended to share one session factory object per application but to use mutiple sessions.

Not clear about your 3 point, can you please elaborate a little.

Hope it helps

coder
  • 4,458
  • 2
  • 17
  • 23