jakarta-eesingletonejbejb-3.1session-bean

Singleton session bean

  1. Singleton session bean has been introduced to address what problems ?? is it only for sharing the data that is common for all the beans ??

  2. How is that problem managed in EJB 3.0 and versions before that ?

  3. If it retains the client specific conversational state , that single instance will be having all the clients'(that are trying to access concurrently) specific data in it?? Will it be secure??

  4. If we can use static final variables and static initializer block or static methods to initialize them (as static variables are also per class data not per instance data) in other session beans, for sharing common data across beans, what is the need of singleton session bean ?

  5. Is it a good design to have business methods in the singleton?? if so, response time for the client requests served by a single instance will be much more than when served by multiple instances.

    Moreover, while singleton bean allows concurrent access of a single bean instance by multiple clients, the default lock type (write lock) in the default concurrency type (container managed) will block all the other threads from accessing the bean until that method is over, and and this seems to be a disadvantage right ??

  6. It will be very helpful if someone could give a clear & simple usecase where no other beans fit as exactly as singleton bean does

Thanks in Advance :)

Solution

    1. Yes.

    2. Typically data was stored in static variables. Static variables are not great for a variety of reasons including unit testing. Additionally, static variables require some kind of synchronization, and a strict reading of the EJB spec does not allow that though in practice it worked fine.

    3. Typically the state stored in a singleton is not client-specific but application-specific. For example, caching global configuration state or caching global state from a database, perhaps refreshing with a periodic non-persistent timer.

    4. There isn't, but see #2.

    5. No, singleton beans are probably not a good fit for request-based business logic. Yes, the default is CONTAINER concurrency with WRITE lock, so only a single thread at a time. You should use @Lock(READ) or @ConcurrencyManagement(BEAN) as needed.

    6. As mentioned in #3, typically "global" application state that needs to be shared across all beans. I find singleton session beans are useful for application configuration and for managing application-wide timers.