Threadlocal not getting cleared on weblogic 11g

[mgorav]

Hi All,

I am creating thread local using ThreadlocalTargetSource. The application when deployed on weblogic application server, its observerved that the thread local variable not getting cleared and hence subsequence request get the old thread local values.

Note :- We are using weblogic 11g and spring 3.0

The thread local are configured as follows

<bean id="ohiContext" class="com.oracle.healthinsurance.context.OhiConte xt"
scope="prototype">
<property name="locale">
<value>#{ohiDatagridContext.defaultLocale}</value>
</property>
<property name="username">
<value>10</value>
</property>
</bean>
<bean id="ohiContextThreadLocalTs" class="org.springframework.aop.target.ThreadLocalT argetSource">
<property name="targetBeanName">
<value>ohiContext</value>
</property>
</bean>


<bean id="ohiBusinessContext" class="org.springframework.aop.framework.ProxyFact oryBean">
<property name="targetSource"><ref local="ohiContextThreadLocalTs"/></property>
<property name="proxyTargetClass"><value>true</value></property>
</bean>


The OhiContext looks like

public class OhiContext extends HashMap<Object, Object> implements DisposableBean {
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(OhiContext.class);
private static final long serialVersionUID = 1L;
private static final String KEY_USERNAME = "username";
private static final String KEY_LOCALE = "locale";

public void setLocale(Locale locale) {
if (locale == null) {
// TODO: is this correct behavior?
this.put(KEY_LOCALE, MLSHandlerUtil.getDefaultLocale());
} else {
this.put(KEY_LOCALE, locale);
}

logger.debug("setLocale(Locale) - Thread Local set >>> " +
this.values());
logger.debug("setLocale(Locale) - Thread Local Set <<<< " +
this.keySet());
}

public void setUsername(Long username) {
logger.debug("setUsername(Long) - Thread Local set >>> " + username);
this.put(KEY_USERNAME, username);
}

public Long getUsername() {
return (Long) this.get(KEY_USERNAME);
}

public Locale getLocale() {
return (Locale) this.get(KEY_LOCALE);
}

@Override
public void destroy() throws Exception {
this.clear();
}
}

[mgorav]

NOTE :-
1) ohiDatagridContext is a singleton beans that set the default value.

But OhiContext can be altered via UI (war) or Webservice (war).

2) UI and Webserivce war bundled in a EAR and parent child context is configured. OhiContext (thread local) is configured in the parent context.
The child context are :- UI & Webservices

[mgorav]

Spring team, can somebody please respond and help ???

[mgorav]

I am eagerly awaiting reply

[mgorav]

calling destroy method of the threadlocaltarget source, after the webserice/ui request is completed solved the problem.

Thanks for not giving answer and inspiring me to dig deeper ;-)

[Costin Leau]

Hi mgorav,

If you need to call destroy, then it's likely your object scope is not a thread-local. While your approach works, consider implementing your own scope since then you don't have to manage your objects by yourself (since you might forget to call destroy in other parts of the code and you end up with leaks).

[mgorav]

Hi,

Thanks.
]You were absolutely correct. Calling destroy on thread local was very dangerous and leads to unpredictable results (like spring batch RepeatContext which also used thread local internally - miss behaved in its async task executor)

So what I did, I am totally relying on spring to call the destroy on threadlocal and I only clears the data - content of the prototype bean in the threadlocal.

[kiran.vaddadi]

Hi,

Does this mean the objects referred by the thread local are not gc'd until the application is shutdown? Weblogic server uses thread pools, if I am correct this will lead to memory leaks.

http://static.springsource.org/sprin...getSource.html

[sentikakar]

All the MessageSourceAccessor methods have a variant which takes a locale. The presumption right now is that if you care about the locale, you use those variants.

That is, you use something like LocaleChangeInterceptor or whatever mechanism makes sense to set the current locale on each request. View code typically uses RequestContext.getMessage to get messages in the proper locale without worrying about things. Controller code when working with the BindException 'errors' object doesn't have to worry about the locale either as that is handled for the view. But other controller code that needs to get messages does have to use something like RequestContextUtils.getLocale() to get the current locale, and supply it as the locale when resolving these messages. Additionally, any other objects that extend from ApplicationObjectSupport and use the supplied MessageSourceAccessor have to get the locale from somewhere (not-determined) if they want to override the default locale...

I agree that the idea of binding the current locale to a thread be used as the default locale by MessageSourceAccesor would probably make some sense, for use in the last two cases above.

WEB DESIGN SEARCH ENGINE OPTIMIZATION PAY PER CLICK SOCIAL MEDIA MARKETING Dgtpoint

STATIC WEB DESIGNING
DYNAMIC WEB DESIGNING