ServiceLocator with stateful session beans EJB 3.0

Discussions

EJB design: ServiceLocator with stateful session beans EJB 3.0

  1. Dear all, According to the Core J2EE Patterns, ServiceLocator is supposed to cache EJBHome objects. Now suppose I work with stateful session beans in EJB 3.0. I don't have home objects any more, so I'd cache the object returned by context.lookup() (see code below). But that means that several users would have access to the same stateful bean (the cached one), which is not what we want. How to solve this issue in the context of EJB 3.0 ? public class ServiceLocator { /** * Singleton Instance of this class */ private static ServiceLocator serviceLocator = null; /** * InitialContext object */ InitialContext context = null; /** * Cache where the objects can be stored for later * retrieval. * This enhances the performance. */ HashMap serviceCache = null; /** * Constructor to initialize the class * * @exception NamingException In case an exception is * generated */ public ServiceLocator() throws NamingException { // Start the initial context context = new InitialContext(); // Initialize the HashMap to store 5 objects serviceCache = new HashMap(5); } /** * Returns the singleton instance * * @exception NamingException In case an exception is * generated * @return Singleton Instance */ public synchronized static ServiceLocator getInstance() throws NamingException { if (serviceLocator == null) { // If the object is not created, then create it serviceLocator = new ServiceLocator(); } // Return the singleton instance return serviceLocator; } /** * This is the method that returns the service * * @param jndiName JNDI Lookup needed for invoking the * service * @exception NamingException In case an exception is * generated * @return Service Object */ public Object getService(String jndiName) throws NamingException { if (!serviceCache.containsKey(jndiName)) { // If the object is not saved in the cache, then do a //lookup and save it serviceCache.put(jndiName, context.lookup(jndiName)); } // Return the required object return serviceCache.get(jndiName); } } Thank you, Sorin
  2. Hi, I think caching stateful session bean is not good idea for EJB 3.0. While it's still valid to cache stateless beans. It's not - for stateful.
  3. Check the life cycle of the statefull beans.There is no pooling.so why pool using service locater?
  4. Ivo, the ServiceLocator pattern has nothing to do with pooling. The question is how to use this pattern (which works fine with stateful session beans before EJB 3.0) in the EJB 3.0 context.
  5. If you are maintaining your user session information in another tier (say web), your user specific stateful session bean reference should be associated with that particular user's session. Subramanian, Kumar [kumar at eminenttech dot com] J2EE Architect Eminent Technology Solutions (ETS) [www.eminenttech.com] Software / Portals / Alfresco / Outsourcing / Proteomics
  6. If you are maintaining your user session information in another tier (say web), your user specific stateful session bean reference should be associated with that particular user's session.

    Subramanian, Kumar [kumar at eminenttech dot com]
    J2EE Architect
    Eminent Technology Solutions (ETS) [www.eminenttech.com]
    Software / Portals / Alfresco / Outsourcing / Proteomics
    Kumar, that's pretty clear. The issue is that still, the ServiceLocator pattern proves its usefulness with or without the web tier. The problem is that the ServiceLocator as described in Core J2EE Patterns is not applicable to EJB 3.0.