Thread Local recommendations in heavy back-end mid-tier server application

Question

Is it recommended to use ThreadLocal to store a Thread Context?

I am building a backend server application where there are typical services that I need to run.

Note: We are not building this over a SOA architecture.

Before the start of each service I need to give it a state which has some Service Contex which is variable map to work up on. This variable map is shared when services are running parallelly.

Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.

Question: Is it a good approach to keep the thread context inside thread local and then building api's over service context to access parameters over these variables.

This would help me to hide the complex behavior and it wouldn't open up my internal things.

Thanks, Aditya

Answer 1

It looks like your server application framework ought to provide you with the means to implement this functionality in a simpler way - unless you are implementing your own framework.

Now for example a service needs to check weather it has to be halted or timed-out based on some thread related parameters.

An EJB container provides this kind of functionality. EJBs also provides a session context and the means to ensure that the context can be restored if execution is transferred between threads (by passivation + activation).