Announcement Announcement Module
No announcement yet.
Thread-safty, Singleton , Ejb Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Thread-safty, Singleton , Ejb

    Could someone please shed some light on Thread-safty and singleton in Spring?
    I understand that the scope of the Spring singleton is “per container”. If I define a bean for class BeanA in a single spring container, then the Spring container will create one and only one instance of the BeanA defined by that bean definition.
    Now if 2 threads, both are using the same beanA instance. Won’t there be a thread-safty issue if BeanA is not Thread-Safe?

    A more real scenario is when using Spring and EJB.
    My ApplicationContext is loading quite a few beans and the initialization of those beans is memory intensive/time consuming.
    So I decided to use ContextSingletonBeanFactoryLocator to load a shared container to be used by multiple EJBs.
    ContextSingletonBeanFactoryLocator loads a single ClassPathXmlApplicationContext which in turn loads exactly one instance of my pojo beans.
    Won’t there be a thread-safety issue if these pojo beans are not thread-safe and multiple EJBs access them concurrently?


  • #2
    You are correct. There indeed is a problem if your objects are not thread-safe. There are different strategies for addressing this problem. One is to not use a ContextSingletonBeanFactoryLocator but have a context for each EJB instance (which is default behavior of the AbstractStatelessSessionBean convenience class). Another is to simulate an EJB pool so that your service has a pool of instances under the cover. Although this begs the question "why not use EJBs?". One reason is you can only pooling to those services which are not thread safe. Another is you can choose your pooling method. You could use a ThreadLocalTargetSource to only create on object per executing thread instead of more tradition take/release form of pooling used by EJBs and provided by Jakarta Commons Pool. Take a look at the "Using TargetSources" section of the reference manual.


    • #3
      to simulate an EJB pool so that your service has a pool of instances

      Hi wpoitras.
      not quite get it when you say "to simulate an EJB pool so that your service has a pool of instances "?
      Assuming using ContextSingletonBeanFactoryLocator, let's say I have a stateless session bean wrapping my pojo. The application server provides a pool of this EJB and when they access the only instance of my pojo, I still have the threadsafety issue.



      • #4
        You have an issue only if your pojos are not threadsafe, so the obvious solution is to make them threadsafe.

        Do you have a real or a theoretical issue? If it's a real issue show us the problem and we can perhaps help. On the other hand if it's a theoretical "what-if" kind of a problem, I'd say you should not bother yourself with it too much. Your pojos provide _stateless_ services and more often then not the intuitive first go at writing that kind of services will result in a threadsafe implementation.

        One of the basic problems with EJBs is that that provide no more then _illusion_ of assured threadsafety. There are ways to write fundamentally broken non-threadsafe classes and there is no way about it. You may want to look up why SingleThreadedModel of servlets got deprecated.


        • #5
          Instead of using a singleton POJO, you create a prototype POJO, then create another Spring bean which is a ProxyFactoryBean using a TargetSource that does pooling and references your POJO. The reference manual has examples.