You’re correct – in Spring world most of the beans are singletons.
- The way I used before (creating new instance each time) is incorrect ?
It is not incorrect since it works. The problem about it is that you instantiate a new instance of DAO on each request – in some cases it might be expensive, and anyway it doesn’t make any sense – why would you need a bunch of DAO instances?
Spring on the other hand not only creates a singleton but also injects DAO’s to services or other DAO’s e.t.c. i.e. does a lot of work for you
- If @Repository is singleton, how does it handle thread safety when there is no such a thing addressed? (Assume it is done by spring proxies)
When you are writing a @Repository bean, you would normally inject there a DataSource or an EntityManager. DataSource.getConnection() method should be thread safe. With regard to EntityManager, Spring will inject a proxy which will behave differently for different threads, i.e. different threads won’t share the same JPA session.
- What is the best practice, @Repository is enough or adding @Scope(‘prototype’) would be better ?
The best practice (or rather a most wide-spread approach) is to just use @Repository
- I don’t see anyone use @Scope(‘prototype’) with @Repository (according to the tutorials, blogs, etc). Is there a well know reason?
The reason is that there’s no profit from creating multiple instances of @Repository beans
- What if my DAO class is accessed by multiple large number of threads with very high frequency? (This is the one I concern the most)
Again here singleton is better than creating a new object for each request. Just avoid redundant synchronization so your threads won’t block on some monitor