1

I'm working on a project where we use MULE and Spring. In the context we create beans that provide the services. All the beans are essentially thread safe singletons. Is this a popular/recommended way of writing services?

user195166
  • 417
  • 5
  • 16
  • I found a url http://blog.webscale.co.in/?p=64 says spring injection is not threadsafe! Contradiction!! Can anyone please help on this? – rock wells Feb 15 '11 at 13:19

3 Answers3

2

By default a bean in spring will be a singleton and it is a very common scenario you describe.

Paul Whelan
  • 16,574
  • 12
  • 50
  • 83
0

Might be problematic performance wise. If you have many threads competing for the same service. The bean is defined thread safe, so acess from different threads would be effectively serialized.

GabiMe
  • 18,105
  • 28
  • 76
  • 113
  • This is really only an issue if you're doing synchronized blocks on some sort of shared state. If you aren't doing any locking for concurrency, the difference in performance for using a singleton is negligible. – Jason Gritman Oct 23 '09 at 16:37
  • This is the issue I'd like to explore; AFAIK attempts to access a singleton will be serialised. The fact that it's a thread safe singleton means there is no need for locking. So, as bugspy.net suggests access will be serialised. Surely this is an inhibitor to scalability? – user195166 Oct 25 '09 at 23:10
  • I am not sure the access to singleton is automatically serialized by Spring. Check this. I think it's the singleton's responsibility to serialize and lock whatever need to be locked – GabiMe Oct 25 '09 at 23:19
0

In our RESTFul service we set up our entry points on a

@com.sun.jersey.spi.resource.PerRequest

basis and

@org.springframework.context.annotation.Scope("request")

which keeps our throughput up but we monitor to ensure that GC is good enough not to bloat the app.

Spring singletons are inherently thread-safe plus this is the default scope -- which performs quite well as we use them in all our web apps.

non sequitor
  • 18,296
  • 9
  • 45
  • 64
  • I'm fairly new to Spring so please bear with me.. When you say "Spring singletons are inherently thread-safe"; don't I still have to write my code in the bean in a thread safe manner for that to be true ie I should not create a new instance of any module level variables as the next thread in might use them? – user195166 Oct 25 '09 at 23:29
  • 1
    Well if you are using Spring for its "dependency injection" then you don't worry about the life-cycle hence you do not manually instantiate your beans - that's why you have Spring. So basically you tell Spring that class `A` is needed to be injected into class `B` and Spring creates `A` and `B` and "injects" an instance of `B` into an instance of `A`. By default Spring creates **singleton** instances of the 2 beans however your classes need to be inherently thread safe i.e. they should be stateless. If you need to keep state you probably need prototype,request or session scope. – non sequitor Oct 26 '09 at 04:36
  • Have a look at this on scopes http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes – non sequitor Oct 26 '09 at 04:38
  • I understand the inj. and life-cycle. My concern is around threads being queued. For my example I have one Spring context. As the documents state there will be one and only one instance of the singleton. Now imagine I have a method named CalculateTax. The class as you say is stateless. Now a request comes in, a thread is created (tA) and it eventually enters the CalculateTax method. Within the same "time frame" another request comes in and another thread is created (tB). Now, here is what I want to understand. AFAIK tB cannot execute CalculateTax until tA has exited the method. Is this true? – user195166 Oct 26 '09 at 06:24
  • doh! you are using request scope so you will not have the potential issue I'm investigating. – user195166 Oct 26 '09 at 08:04
  • got my answer here http://stackoverflow.com/questions/1624044/singletons-and-threads – user195166 Oct 26 '09 at 10:31
  • While this is exactly what I said "i.e. they should be stateless", if they are stateless then you have no issues, i believe the third answer in that question mentions this with reference to "local variables" etc. – non sequitor Oct 26 '09 at 13:19