• Post Reply Bookmark Topic Watch Topic
  • New Topic

Help: can i cache configurations using session bean?

 
david kong
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
quite new to EJB, so my question may looks simple and naive to expert. but really appreciate ur help!

my intention is, use this session bean (ConfigurationServiceBean) to cache the configurations. When the application server starts, it will read the configurations from the XML file and store it in a HashMap. So later other modules can just retrieve the configurations from this bean, instead of reading the file again. And my question is,

1. is session bean able to achieve this?
since session bean may be passivated, removed by the container. That means I may need read the file again to load the configurations, if the bean instance is removed?

2. shall i use stateful or stateless session bean?

--------------------------------------------------------------------------------------
package eshop.service.configuration.ejb;

import java.util.HashMap;

import javax.ejb.CreateException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

import org.xml.sax.helpers.DefaultHandler;

import eshop.foundation.system.config.ObjectSchemaXMLHandler;
import eshop.foundation.system.oc.ObjectSchema;
import eshop.foundation.utility.common.XMLUtility;

public class ConfigurationServiceBean implements SessionBean
{
HashMap objectSchemaMap = new HashMap();

public void setSessionContext(SessionContext sessioncontext)
{
System.out.println("Set sessionContext to ConfigurationServiceBean...");
}

public void ejbCreate() throws CreateException
{
System.out.println("ConfigurationServiceBean will be created...");
}

public void ejbActivate()
{
System.out.println("ConfigurationServiceBean will be activated...");
}

public void ejbPassivate()
{
System.out.println("ConfigurationServiceBean will be passivated...");
}

public void ejbRemove()
{
System.out.println("ConfigurationServiceBean will be removed...");
}

public void parseObjectSchema()
{
if(this.objectSchemaMap.isEmpty())
{
System.out.println("objectSchemaMap is empty.....................");
String uri = "E:\\eshop\\config\\objectschema.xml";
DefaultHandler handler = new ObjectSchemaXMLHandler(this.objectSchemaMap);
XMLUtility.parserXMLDocument(uri, handler, false);
}
}

public ObjectSchema getObjectSchema(String id)
{
return (ObjectSchema)this.objectSchemaMap.get(id);
}
}
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David,

And welcome to the ranch.
Usually caching data is achieved using either singletons or static classes. The idea is that you can have only one class per jvm in order for caching to be optimal. EJBs on the other hand were not designed to achieve neither one of the two: they are not singletons and they cannot have static members either. Therefore they might not be the best candidates for your design.

is session bean able to achieve this?
since session bean may be passivated, removed by the container. That means I may need read the file again to load the configurations, if the bean instance is removed?

They might be, although this is probably not the best approach. You can make SLSBs acting as singletons, through deployment descriptors. Usually containers will allow you setting the initial number ob bean instances in the pool and the maximum number of bean instances in the pool. Setting the both values to 1 you�ll achieve the "singleton" behavior. On the other hand SLSB are neither passivated nor activated and with this configuration the container will never remove the unique bean instance from pool.

shall i use stateful or stateless session bean?

Again a singleton/static class would be a better solution. Use then either a servlet (with load on startup = 1) or a startup class to initialize the cache. However if you really want to go with ejbs then a SLSB will be a better choice over SFSB. Actually SFSB are not even an acceptable solution, since you�ll end up having a cache for each client.
Regards.
 
david kong
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Valentin Tanase:
Again a singleton/static class would be a better solution. Use then either a servlet (with load on startup = 1) or a startup class to initialize the cache. However if you really want to go with ejbs then a SLSB will be a better choice over SFSB. Actually SFSB are not even an acceptable solution, since you�ll end up having a cache for each client.
Regards.[/QB]


Thanks for ur reply. But if I use singleton/static class, and if both the web client and ejb need use this cache service, that means I will have 2 "singleton" instance in the web server and application server. How can i overcome this problem?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The design I was thinking about is feasible when you deploy your app as an ear, having both web components and ejb components deployed to the same server. However if you decide to deploy your web app and your beans separately then the problem will change completely. Before doing that you better review your requirements and make sure you cannot do otherwise (deploying your app as an ear). A first consequence of this approach is that your web components cannot use local interfaces. Hence lot of rmi calls will occur. Think also about implementing kind of command design pattern in order to reduce the number of those rmi calls.
Having said that you might first answer to this question: why do you need to cache the data in both layers? Can�t you design your app to cache the data in your business layer, or presentation layer only? If the answer is still no, then you have two choices: either pack the CachManager singleton with both archives, either use the SLSB acting as a singleton solution. They might be some better solutions as well, but I believe that the nicest solution to your problem could be provided if you decide to change your app design little bit.
Regards.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!