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?
+2
A:
By default a bean in spring will be a singleton and it is a very common scenario you describe.
Paul Whelan
2009-10-23 08:35:35
A:
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.
bugspy.net
2009-10-23 08:59:40
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
2009-10-23 16:37:10
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?
2009-10-25 23:10:56
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
bugspy.net
2009-10-25 23:19:34
A:
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
2009-10-23 16:37:51
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?
2009-10-25 23:29:57
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
2009-10-26 04:36:26
Have a look at this on scopes http://static.springsource.org/spring/docs/2.5.x/reference/beans.html#beans-factory-scopes
non sequitor
2009-10-26 04:38:48
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?
2009-10-26 06:24:48
doh! you are using request scope so you will not have the potential issue I'm investigating.
2009-10-26 08:04:12
got my answer here http://stackoverflow.com/questions/1624044/singletons-and-threads
2009-10-26 10:31:42
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
2009-10-26 13:19:01