views:

1311

answers:

4

I have a Web application using spring and hibernate and struts (it runs on Tomcat)

The call sequence is something like this...

Struts action calls spring service bean which in turn calls Spring DAO bean. The DAO implementation is a Hibernate implementation.

The question is Would all my spring beans be running in the same thread ? Can I store something in the ThreadLocal and get it in another bean?

I am quite sure this would not work in Stateless Session Bean. The EJB container can (or will) spawn a new thread for every call to the session bean

Will the spring container do the same? i.e. run all beans in the same thread ?

When I tried a JUnit test - I got the same id via Thread.currentThread().getId() in the Test Case and the two beans- which leads me to believe there was only one thread in action

Or is the behavior unpredictable? Or will it change when running on Tomcat server ?

Clarification I do not wish to exchange data between two threads. I want to put data in the ThreadLocal and be able to retrieve it from all beans in the call stack. This will work only if all beans are in the same thread

+3  A: 

Spring doesn't spawn the threads. Tomcat does. Spring is just creating and wiring up the objects for you.

Each request from the browser is processed in one request. Is it Tomcat that handles the request. It is Tomcat that creates the thread to process the request.

Assuming you have just created a singleton bean in Spring called "X". Then the same instance of X is used by all requests.

The Spring beans don't live in a thread. They are just allocated on the heap.

A_M
So when running under Tomcat- will my end to end flow be under one thread ?
RN
Yes, assuming everything is on the same app server instance.
A_M
This is best explanation so far.
matt b
+1  A: 

Would all my spring beans be running in the same thread ? Can I store something in the ThreadLocal and get it in another bean? AFAIK for the components you mentioned (service bean, DAO bean - i guess they are plain spring beans), Spring does not spawn a new thread. I do not understand your use case (ie, exchanging data between two threads).

For most webapps, a new thread is spawned for each new request, and if you want to share data between two requests you normally: - use the get/post parameters to pass the data - use the session to share data

To answer your question, I'm pretty sure the spring container does not spawn threads for most components.

Miguel Ping
I do not wish to exchange data between two threads. i want to put data in the thread and be able to retrieve it from all beans in the call stack. This will work only if all beans are in the same thread...
RN
A: 

Yes, you can do this. The same thread will be used to execute your action so the ThreadLocal will work. Typically, the same thread is used for the stateless session bean as well, assuming it is running in the same app server instance. I would not depend on this though, as it is probably vendor dependent.

We use this technique to access the callers identity anywhere in the code. We use session beans and jms as well, but explicitly pass the information between containers and set the ThreadLocal at each entry point. This way it doesn't matter if the bean (session or mdb) are local or not.

Robin
I didn't think he was actually using a stateless session bean? I was presuming he was using POJOs in Spring as an alternative.
A_M
and by default, Spring will create your beans as singletons, meaning that the same instance is shared across all requests. But if he stores something in ThreadLocal, it doesn't matter.
matt b
I assume your point about POJO's is correct, but he did mention that he didn't think it would work, so I assume this may be another alternative he was thinking of (with or without Spring). I just thought I would give him some information regarding that as well based on my own experiences doing something similar.
Robin
A: 

In addition to all the other answers, I will just add the following:

Normally the only reason to switch threads is because of some requirement for parallellity. Since this normally does not come for free in terms of complexity, you will usually be clearly informed when this happens.

Switching threads within what appears to be a single-threaded processing of a request is actually extremely complex. This will normally only happen at one place in a container, and this is usually handled by tcp/ip socket readers that receive the request from the external clients. These reader threads usually determine which thread(pool) should process the request and forward the request to that thread. After that the request stays with that thread.

So normally the only thing that will/can happen is that additional threads get created for parallelity or asynchronous processing (like JMS).

krosenvold