EJB design: The missing piece: Where to put general lookups?

  1. Hello everyone,

    I have read several books on EJB design yet I am still unclear how/where to put lookups that do not correspond to domain objects. (For example, I want to query a table and get a list of states)

    Anyone care to share their strategy?

    Could someone point me in the correct direction?

    I appreciate it.
  2. Hi,

    Seems here you are talking about the reference data which are mostly static in nature.

    These data can be put in database or XML files based on the requirement. If any change in the data can be done manually (i.e. manual editing etc.) then XML can be better choice. If the editing has to be done through application database is the best storage.

    Now to get/modify this data from database general design pattern is to create a session bean facade to handle all such tables. The session bean can directly talk to the persistence layer. Best choice or JDO. Use of Entity Bean in between is strongly discouraged as it will be an over kill.

    At the application layer use a delegate class to call the session bean. However also use some singleton hash maps which will cache these data at this layer, as these data will be rearly changed.
    The best pattern is to use recreate the cache whenever data is changed. In case of a clustured environment to ensure the cached data is replicated in all the servers MDB can be used.

  3. Hi Sourav

    This looks like a good approach in managing data of this type. However, I have a few questions as I am grappling with this exact issue at this stage of our project (I prefer the database approach):

    1. Does one still use the session facade to update the static data?

    2. More importantly, what is a good way of detecting ftom the application delegate (which stores the cache) that the data has been changed and should be recached?


  4. Hi Chris,

    Here goes the answers.

    1. If you are using Database for storing the data, you really have to use the Session Facade as that is the getway for the web tier to the ejb tier which eventually talks to database. It is nno way a good approach to directly call database frob web tier as a short cut. It will spoil your J2EE framework.

    2. This is an interesting question. The solution depends on the usage pattern of the application. However, in any case, whenever the actual data is getting changed (for example administrator of the application is adding some more values to the country table) at that time only the cach should get updated. Also whenever the server starts the cache should be re-generated. In that case, in general, if someone uses singleton pattern, whenever system finds the cache is empty it will regenerate the cache.

    Hope this ansers your query.

  5. Hi Sourav

    You refer to a "general design pattern is to create a session bean facde to handle all such tables" in your response. Do you where I can find docs on this?

    Another thing using this approach, I assume that as we are no longer using EJB's, although we will still have database tables for this kind of data, we will hold direct attributes (ie keys) from any EJB that we references this data eg. if we Country as a static table with primary key countryId, then if EJB Person references country, it would look like this:

    public class PersonBean implements EntityBean {
      public abstract int getCountryId();

    as opposed to (if Country was an EJB):

    ublic class PersonBean implements EntityBean {
      public abstract Country getCountry();

    Am I correct?


  6. Hi Chris,

    I don't have any particular document on this pattern. This is a pattern we used in our project and it worked fine. However, if you're only looking for famous session bean facade pattern, you can get it in EJBDesignPattern book (which is now freely downloadable from this site itself) as the first described pattern.

    Now regarding your second point I'm not sure why you are saying that you are not using EJB. At least you are using Session Bean (EJB) which will serve as a facade to your application/EJB tier. Whether you will be internally design your domain model with entity EJB or not that is separate issue. For deciding on whether you need to go for entity EJB for designing the domain model or not please check out the same book (mentioned above). It is wonderfully discussed there.