Spring SimpleThreadScope in a web app : part of container pool?

Question

Have a service that exposes crypto functions. We don't need a clean up nor do I want objects to be created every time/ every session. But i need a separate object per thread.

In a web app - will the scope be the web container's thread pool ?

Is it same in spring 3 and 4 implementation?

Another place we plan to use this is to cache SimpleDateFormat objects. Again don't need a clean up method.

Answer 1

Since version 3.0, Spring has a basic notion of thread scope : the SimpleThreadScope. It looks like it can feet what you ask, but it has some limitations :

• it is not registered by default with containers but must explicitely be
• it performs no cleanup on its beans.

If you can accomodate with those limitations, you can register the scope programatically :

Scope threadScope = new SimpleThreadScope();
appContext.getBeanFactory().registerScope("thread", threadScope);

or in xml config :

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
    <property name="scopes">
        <map>
            <entry key="thread">
                <bean class="org.springframework.context.support.SimpleThreadScope"/>
            </entry>
        </map>
    </property>
</bean>

This works the same in Spring 3 and Spring 4. If you want to inject a thread scoped bean in a singleton bean, you have to declare an aop scoped-proxy on it :

<bean id="bar" class="x.y.Bar" scope="thread">
    <property name="name" value="Rick"/>
    <aop:scoped-proxy/>
</bean>
<bean id="foo" class="x.y.Foo">
    <property name="bar" ref="bar"/>
</bean>

(All examples from Spring Framework Reference Documentation).

If you have to do some cleanup, you can look at this document Spring by Example Custom Thread Scope Module that shows an enhanced version of SimpleThreadScope.

But I am not sure you really want that, unless all threads continuously use the thread scoped beans, or memory is not really a concern. Because in that design pattern, if only one session at a time needs the bean, but it is served by several threads (assuming other requests do not need the bean), all the threads will get a different instance of the bean, whereas with a pool only one instance would have been used.

You will find an example of using a CommonsPoolTargetSource with Apache Common Pools in this other post from SO How to pool objects in Spring?. Extract from the post :

<bean id="simpleBeanTarget" class="com.bean.SimpleBean" scope="prototype"/>

<bean id="poolTargetSource" class="org.springframework.aop.target.CommonsPoolTargetSource">
    <property name="targetBeanName" value="simpleBeanTarget" />
    <property name="maxSize" value="2" />
</bean>

<bean id="simpleBean" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="targetSource" ref="poolTargetSource" />
</bean>

The example use a ProxyFactoryBean to give an aop proxy to allow injection of simpleBean in a singleton bean, provided it is injected as an interface.

Answer 2

ThreadLocal has thread scoped objects. Secondly, SimpleDateFormat and DateFormats in general are not synchronized. So be aware of thread issues there. By the way, when you say 'per thread', did you mean per request? As the java doc for SimpleThreadScope says, it is typically preferable to use RequestScope in web environments.

Spring can create beans with specific scopes like prototype, request, you might want to consider. And as @Sairam mentioned, life cycle management is also worth a thought.

Answer 3

In spring framework, to get a separate object per thread, we could achieve this by having the bean scope as prototype.

From the reference.,

<bean id="accountService" class="com.foo.DefaultAccountService" scope="prototype"/>

There is no change in Spring 3 & 4 with respective to this specific case. Regarding the clean up of objects, prototype scope behaves differently.,from the same reference document.,

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean: the container instantiates, configures, and otherwise assembles a prototype object, and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype bean(s) are holding.

Answer 4

An solution for you:

1. provide your own FactoryBean to create your service bean.
2. in your FactoryBean, you shuld use ThreadLocal to hold your bean, if not exist, create one and save it to ThreadLocal, next time, retrieve it from ThreadLocal!