Announcement Announcement Module
Collapse
No announcement yet.
Is thread-safety a non-issue for Spring? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is thread-safety a non-issue for Spring?

    I'm used to working in environments where the container guarantees thread-safety, i.e. each instance of an application class is always run by at most one thread at a time.

    I've tried hard to find any material on best practices regarding thread-safety in Spring, in the Reference Documentation, in this forum and out in the wild, but I don't get the picture. The message seems to be "use the singleton scope and make sure your beans are thread-safe".

    I'm thinking about highly concurrent applications with a web UI, some JMS queues and scheduled tasks on top. If all services are singletons and if Spring cannot guarantee thread-safety, then any service class with any instance variables not injected by Spring is a potential risk.

    Making a class thread-safe is not trivial. Most third-party classes do not even document whether or not they are thread-safe, so you have to assume they are not thread-safe and synchronize them manually or spend a lot of time reviewing the sources to convince yourself they are thread-safe.

    That doesn't sound like a smart solution.

    If there is a better approach, then the Reference Documentation should dedicate a section to it. If there is none, I'd rather not use Spring...

    Regards,
    Harald

  • #2
    I'm used to working in environments where the container guarantees thread-safety, i.e. each instance of an application class is always run by at most one thread at a time.
    It's trivial to implement this kind of "thread safety" in Spring with a method interceptor that synchronizes all the calls on the receiver object. However, I wouldn't want to do that in general. Thread safety must really be thought for every class. If a third-party class is not thread safe or you're not sure about it, you have two options: ask the maintainer of the class to fix it, or fix it yourself, either coding a wrapper, or modifying the code of the class itself if it's under your control.

    Comment


    • #3
      As a rule, I wouldn't call any kind of method interceptor trivial. My notion of trivial is putting a @Stateless annotation on a POJO to make it pooled and thus implicitly thread-safe.

      Synchronizing on a given object is indeed not the solution I was looking for. Thread-safety should not preclude concurrency.

      Regards,
      Harald

      Comment


      • #4
        Originally posted by hwellmann View Post
        As a rule, I wouldn't call any kind of method interceptor trivial.
        Well, let's put it this way: in Spring is as trivial as it can be in Java.

        Originally posted by hwellmann View Post
        My notion of trivial is putting a @Stateless annotation on a POJO to make it pooled and thus implicitly thread-safe.
        I don't follow you. If an object is stateless, then it's thread-safe by definition, so why would you need pooling?
        If an object is stateful, and you want pooling, I don't think Spring offers something built-in for that. You could code a pooled FactoryBean implementation; however, in such a scenario, how would you release an object to be put back in the pool? I suppose you need an API for that.

        Originally posted by hwellmann View Post
        Synchronizing on a given object is indeed not the solution I was looking for. Thread-safety should not preclude concurrency.
        Ok, I agree.

        Comment


        • #5
          If an object is stateless, then it's thread-safe by definition, so why would you need pooling?
          I mean "stateless" in the sense of "does not save state between calls from the same client", having the EJB spec in mind, of course.

          A public method called by the client may call other private methods of the given object, and these methods may communicate via instance variables of the object. This is not thread-safe, if there is a concurrent call by some other client.

          Of course you can program without instance variables, passing all information in method parameters, but then you're losing a key feature of OO design.

          Comment


          • #6
            Originally posted by hwellmann View Post
            I mean "stateless" in the sense of "does not save state between calls from the same client", having the EJB spec in mind, of course.
            I don't know EJB at all, but to me that's a strange definition of "stateless".

            Originally posted by hwellmann View Post
            A public method called by the client may call other private methods of the given object, and these methods may communicate via instance variables of the object. This is not thread-safe, if there is a concurrent call by some other client.
            Of course it's not, because there's mutable state involved (that's why "stateless" doesn't sound right to me).

            Originally posted by hwellmann View Post
            Of course you can program without instance variables, passing all information in method parameters, but then you're losing a key feature of OO design.
            Instance variables are the state of the object. Using them just as temporaries to pass information between methods is not very OO, in my opinion, and I don't see the point in doing it altogether. Probably we have very different programming styles

            Anyway, to try to return back on topic, I discovered that Spring does support some form of object pooling by using Apache commons pool, some pointers:

            http://blog.arendsen.net/index.php/2...art-i-pooling/
            http://static.springsource.org/sprin...getSource.html

            However, it's not as trivial as a @Pooled (or @Stateless) annotation on the bean class.

            Comment

            Working...
            X