1 2 Previous Next 16 Replies Latest reply on Mar 9, 2009 7:30 PM by rafique

Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 5, 2009 12:43 PM

I have a javabean component in application scope which is stateless of course, the only field entityManager is injected with seam managed persistent context (which itself is in event scope I guess):

@Name("userDAO")
@AutoCreate
@Scope(ScopeType.APPLICATION)
public class UserDAO {

@In
protected EntityManager entityManager;

...

}

The UserDAO is injected in UserService which is then exposed as jax-ws endpoint with @WebService, all are application scoped POJO, no EJB.

This works fine with a single request at a time, but in case of multiple requests (I used a thread pool in client) it randomly produces multiple exceptions and then hangs the server up in case of 5/10 concurrent threads.

Some of the exceptions are following:

2009-03-05 20:16:52,756 ERROR [org.hibernate.AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: possible non-threadsafe access to the session
     at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:100)
     at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
     at org.hibernate.loader.Loader.doQuery(Loader.java:729)
     at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
     at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
     at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
     at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
     at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044)
     at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395)
     at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
     at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
     at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
     at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
     at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
     at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
     at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
     at org.hibernate.type.EntityType.resolve(EntityType.java:379)
     at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116)
     at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
     at org.hibernate.loader.Loader.doQuery(Loader.java:729)
     at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
     at org.hibernate.loader.Loader.doList(Loader.java:2220)
     at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
     at org.hibernate.loader.Loader.list(Loader.java:2099)
     at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
     at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
     at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
     at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
     at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
     at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:80)
     at com.moveplot.core.dao.jpa.UserJPADAO.findByAuthToken(UserJPADAO.java:95)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)

and this one is frequeent:

java.lang.IllegalStateException: EntityManager is closed
     at org.hibernate.ejb.EntityManagerImpl.getSession(EntityManagerImpl.java:42)
     at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:92)
     at org.jboss.seam.persistence.EntityManagerProxy.createQuery(EntityManagerProxy.java:81)
     at com.moveplot.core.dao.jpa.UserJPADAO.findByAuthToken(UserJPADAO.java:92)
     at sun.reflect.GeneratedMethodAccessor588.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
     at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
     at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
     at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
     at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
     at com.moveplot.core.dao.jpa.UserJPADAO_$$_javassist_4.findByAuthToken(UserJPADAO_$$_javassist_4.java)

also this one:

2009-03-05 20:16:52,777 INFO  [org.hibernate.event.def.DefaultLoadEventListener] Error performing load command
org.hibernate.SessionException: Session is closed!
     at org.hibernate.impl.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:49)
     at org.hibernate.impl.SessionImpl.getPersistenceContext(SessionImpl.java:1823)
     at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:182)
     at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
     at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
     at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
     at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
     at org.hibernate.type.EntityType.resolve(EntityType.java:379)
     at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116)
     at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
     at org.hibernate.loader.Loader.doQuery(Loader.java:729)
     at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
     at org.hibernate.loader.Loader.doList(Loader.java:2220)
     at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
     at org.hibernate.loader.Loader.list(Loader.java:2099)
     at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
     at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
     at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
     at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
     at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
     at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:80)
     at com.moveplot.core.dao.jpa.UserJPADAO.findByAuthToken(UserJPADAO.java:95)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
     at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
     at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
     at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
     at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
     at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
     at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
     at com.moveplot.core.dao.jpa.UserJPADAO_$$_javassist_7.findByAuthToken(UserJPADAO_$$_javassist_7.java)

Nature of these exceptions suggest that it is a cuncurrency related issue: entityManager injected by seam is being shared by multiple threads. My question is if this is expected behavior for an application scoped component? Shouldn't seams bijection take care of the concurrency or synchronization for application scoped components?

Thanks in advace.

1. Re: Concurrency issue: Aren't application scoped components threadsafe?

pedrosena Mar 5, 2009 1:50 PM (in response to rafique)

May I ask you WHY are you using your DAO as an application scoped component?

The idea sound strange for me.

Regards,

PS
Actions
2. Re: Concurrency issue: Aren't application scoped components threadsafe?

titou09 Mar 5, 2009 2:10 PM (in response to rafique)

What version of seam are you using?

We used to get the same problem in earlier versions of seam and I opened a few JIRA on this
For us it is Ok in the latest version of seam. It was due to a bug in BijectionInterceptor (Search on this in JIRA)
Actions
3. Re: Concurrency issue: Aren't application scoped components threadsafe?

joblini Mar 6, 2009 2:33 AM (in response to rafique)

I guess @Synchronized should be used.

My Link
Actions
4. Re: Concurrency issue: Aren't application scoped components threadsafe?

joblini Mar 6, 2009 2:35 AM (in response to rafique)

Why not put the component in Conversation scope?
Actions
5. Re: Concurrency issue: Aren't application scoped components threadsafe?

swd847 Mar 6, 2009 3:44 AM (in response to rafique)

Your bean should be in the STATELESS pseudo scope, not in the application scope. If you use @Syncronised you will kill concurrency, and risk random timeout errors if a thread does not get access to the bean in time.

What is actually causing your errors is something like this:

Client 1 accesses bean, entityManager is injected
Client 1 starts doing entityManager stuff
Client 2 access bean, client 1s entitymanager is replaced by client 2's entitymanager
Client 2 does entityManager stuff, and so does client 1, both using the same EntityManager.

Depending on the actual ordering of these requests, the hibernate error message will be different each time.
Actions
6. Re: Concurrency issue: Aren't application scoped components threadsafe?

joblini Mar 6, 2009 3:50 AM (in response to rafique)

As I understand it, the Seam documentation recommends Conversation scope for a web service, except for RestEasy, where the given choices are application or stateless.
Actions
7. Re: Concurrency issue: Aren't application scoped components threadsafe?

swd847 Mar 6, 2009 4:02 AM (in response to rafique)

It actually recommends using stateless session beans or POJO's as web services, and if conversational web services are required then use the stateless beans as a facade to conversation scoped ones (section 24.2.1). If it really is a stateless service, then is should be a stateless bean (either stateless POJO or SLSB).
Actions
8. Re: Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 6, 2009 6:41 AM (in response to rafique)

Well, what is your suggestion?
Actions
9. Re: Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 6, 2009 6:54 AM (in response to rafique)

I am using latest seam version 2.1.1.GA with jboss 4.2.3/jdk6. Can you please mention JIRA number for the bug? (my search didn't hit anything relevant)
Actions
10. Re: Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 6, 2009 7:14 AM (in response to rafique)

As you can see, there is no state associated with the DAO or services, ceating separate instances to serve every conversation doesn't really make much sense.
Actions
11. Re: Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 6, 2009 7:54 AM (in response to rafique)

Hi Stuart,

Thanks for your explanation. I was under the impression fields injected by @In will be at least protected from thread corruption by seam interceptors. It seems I was completely wrong.

I used application scope instead of stateless as you mentioned its a pseudo scope; which means every invocation to the component will create a new instance (please correct me if I am wrong), since these are POJO components I am not getting instance pooling from ejb container resulting in proliferation of unused objects and heavy load on GC. Does seam have something like that for POJO stateless components?
Actions
12. Re: Concurrency issue: Aren't application scoped components threadsafe?

rafique Mar 7, 2009 12:10 PM (in response to rafique)
Thinking of other solutions retaining components in application scope:

1. Using ThreadLocal instead of injection to share entityManger using a custom filter. But seam events may not work in this case.

2. Lookup entityManager from event scope using a method rather injected field:

@Name("userDAO") @AutoCreate @Scope(ScopeType.APPLICATION) public class UserDAO { protected EntityManager getEntityManager() { return (EntityManager) Component.getInstance("entityManager"); } ... }
Actions
13. Re: Concurrency issue: Aren't application scoped components threadsafe?

swd847 Mar 8, 2009 11:00 PM (in response to rafique)

Option 2 is probably the best, (well SLSB's would be the best but it sounds like this is not an option).

Stuart
Actions
14. Re: Concurrency issue: Aren't application scoped components threadsafe?

titou09 Mar 8, 2009 11:24 PM (in response to rafique)

I was taking about JBSEAM-3295 and JBSEAM-3659 (and JIRA 3652 that was similar for PAGE scope components)
Actions

1 2 Previous Next

Go to original post