Announcement Announcement Module
Collapse
No announcement yet.
if ThreadLocal is devil on clustering world, how spring security survive? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • if ThreadLocal is devil on clustering world, how spring security survive?

    I had a post in another forum to ask opinion about ThreadLocal. Basically I want to use a ThreadLocal variable to keep my method context info so that I don't have to carry it over cross the board as a parameter. I got a reply suggested that T.L. in clustering is a bad practice.

    Now I'm more confused: Spring security saves user authentication token in ThreadLocal (to be exact, in SecurityContext). If TL breaks J2EE server's clustering management mechanism, how can we try Spring security? It must have other explanation.

    Any opinion?

  • #2
    You'll have to explain what you think the problem is first - i.e. what makes ThreadLocal the "devil in the clustering world" and why don't you think Spring Security should use them?

    ThreadLocals are local to a single JVM (as are threads) and are typically used to carry the security context for the duration of a single request. They don't have any impact on other JVMs in a cluster.

    Comment


    • #3
      I agree with you, and your answer is what I believe! Since I don't have much knowledge of ThreadLocal and I asked the question:"I want to user ThreadLocal to save my method context info so that i don't have to pass it cross all my methods in the same thread". Here's the reply I got:
      "Clustering" refers to running an application on multiple machines for capacity purposes. J2EE has some elaborate mechanisms built in that allow objects to be transparently migrated from one machine to another in a cluster. Any dependence on the specific JVM in which an object lives -- such as using static variables, or ThreadLocals (which are effectively another kind of global variable) -- breaks these mechanisms. Don't do it.
      I don't know why J2EE make ThreadLocal a threat. Since all the methods call in my application is invoked by one request from browser, therefore these methods invocation should live and die w/ the thread w/in single JVM. This thread for servlet request will never propagate across the cluster. Why can't use threadLocal, as suggested above?

      Comment


      • #4
        Why don't you continue the discussion in the original forum and ask the person to expand on their argument? They may be referring to the use of EJBs and calls which span multiple JVMs.

        Comment

        Working...
        X