Post your EJB tips in the EJB Strategies, Tips & Idioms chapter


News: Post your EJB tips in the EJB Strategies, Tips & Idioms chapter

  1. The most fun chapter of the EJB Design Patterns book has been posted for review. The EJB Strategies, Tips, and Idioms chapters is the beginning of a collection of fine-grained tips for designing and implementing EJB applications. Tips that are two small to be patterns are put in this chapter. You can submit your own tip to this chapter and have it published in the book.

    This is the fun chapter I was waiting for, in which we can post all the other good ideas about EJB design that are too small to be considered patterns, but too important not to have in the book. Many more tips are going to be written here in the comming week, immortalize your own name and thoughts by contributing!

    Check out EJB Design Patterns.
  2. This is great! I posted a message asking about this on the discussions and some knucklehead told me to go read the blueprints!

    Some of my patterns, or rather, some I have stolen from friends and collegues and improved ;^)

    1) ResourceFactory - (I know I know...this is no new one)
    How and what I implement is interesting however. The class is all static methods and static Hashtable member fields. Each method looks for a specific type of "resource" like a DataSource, EJBHome interface, etc. In each case the method looks to see if the object is in a Hashtable as a cached item. If it is returned. If not it is looked up in a jndi tree, placed in the Hashtable so it can be obtained without expensive lookups the next time, and returned. The class also has 2 private methods which get initial context, and another that uses the initial context and the item desired to get it from a jndi tree.

    2) ConnectionManager (I know I know, like its new....)
    I actually create 2 types. One with fine grained control, and another which is more "black box" which takes care of things behind the scenes for you. This class is instantiated and used by any class which wants a connection to a database. The key here is that the majority of the logic is in this class so that I can do most of the debugging inside it, instead of in every class which uses it to do the same activities. The connection you use is cached for the duration of the activity. The connection is hidden inside of this class so noone can make alot of mistakes with opening and closing resources like connections, result sets, and statements.
  3. Hey Jonathan,

      These sounds like good ideas. Your resource factory sounds a lot like the EJBHomeFactory pattern I wrote up.

    Why don't you send me back the tips document with these ideas written up, with a minimial code example or something?


  4. Hi
    I have been thinking about pattern similar to presented by Jonathan and I had also ready Home Factory pattern.
    One issue that bothered me though is synchronization. I guess I must be missing something but others may have similar concern so it would be worth elaborating when presenting this pattern.
    The Home Factory pattern uses the HashMap which is not really synchronized. What will happen if the the Home interface object is just being stored in the HashMap while other thread will try to read this incomplete reference?
    One could see the problem by seeing it from two angles:
    <li> High (spec) level. HashMap spec says: <i>If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings ...</i>
    <li> Low bytecode level ;-) - Simplifying one could imagine the reference as being half-stored when only some the bytes expressing the object reference have been written to the destination. It is no longer null, but it is not the correct reference yet.
    It really bothers me from few days and I would appreciate your comments on that.
  5. Hi,

    Definitely "synchronized" keyword is needed in a distributed environment. But then, if EJB client is another EJB, we have problem because "synchronized" should not be used with EJB according to EJB specs.

    We are facing exactly that problem. Our EJB application has to call EJB services of another EJB appl running on different machine. If, from our bean, for every remote call we do a lookup of remote bean, our server often crashed due to "Too many socket open" error after few hours.

    We have applied the HomeFactory pattern (and solved "too many sockets open" error) with some modifications to make the singleton a readonly one, like following:
      class EJBHomeFactory {
         public static final EJBHomeFactory singleton = new EJBHomeFactory();
         private MyEJBHome home = null;
         private EJBHomeFactory() {
           home = lookup the bean here;

    The home reference is looked up only when this singleton is loaded, because we don't know other approach that can avoid "synchronized". The problem is, if due to some reasons, the home reference becomes invalid then we have to restart our appl server to do the lookup again.

    Does anyone have a better approach?

  6. Michael,

     If you look at the code sample, I belive I wrapped the hashmap with a Synchronized Map, which should alleviate the problem you mentioned.

  7. Thanks Floyd,
    I've been looking at ejbpatterns-ejbhomefactory-july18.doc and did not find the SynchronizedMap there. But now it is clear.

  8. Why don't you use a Hashtable instead of synchronizedMap(new HashMap())?
    Does the Hashtable has any drawbacks I am not aware of?

    A quote from
    ....if you need synchronization, a Hashtable will be slightly faster than a HashMap synchronized with Collections.synchronizedMap.

    Thanks Michael
  9. Hi Floyd,

    I had studied the EJBHomeFactory pattern presented in your book. I also look at the above message related to this kind of patterns in this forum. However, I still have some questions related to this pattern.
    My question are following:
    I) Effectiveness of using the EJBHomeFactory in multi threads environment.
       1) The EJBHomeLocalFactory is a singleton object and it saved the
          Home interface of an EJB in a map. Thus only one copy of a particular
          Home interface was saved in the map. I had a servlet that accesses the
          EJBHomeLocalFactory in its body to lookup a Home (myBeanHome). Jboss
          application initialized 10 instances of this servlet. For some reasons
          that 10 instances of this servlet are used by users. Thus all 10
          instances of that servlet call to the EJBHomeLocalFactory to lookup the
          same Home object (myBeanHome).

          Q1)Deos all 10 instances of that servlet sequentially gain accesses to the
          Q2)Does all others instances of that servlet MUST wait util the first one
             finished looking up the Home object (myBeanHome) before other
             instances of that servlet can access the lookup method of the
          Q3) How does the use of the EJBHomeFactory pattern improves the
              effectiveness of resouces accessing for the above scenario.

    II) Maintainability of ejb-refer in the web.xml and jboss-web.xml files?

    Thank you in advance for your help.
  10. Hi Jonathan,

    Is that possible you can post you ResourceFactory and ConnectionManager code or send a copy to me? I'm very interested in this topic. I did a similar class for lookup EJBHome and DataSource. But nothing creative, pretty much use Floyd's EJBHomeFactory, added another lookup for DataSource and also retreive initial_context_factory and provider_url from a property file.

    Thx, Dave
  11. In case of using EJBHomeFactory pattern, how do you implement security? Since initialcontext is instantiated/assigned value only once.
  12. We need to have the answer to the above question too!!!
    please, Marinescu : )

    Emerson Cargnin
  13. My question revolves around the EJBHomeFactory. I have the EJBHomeFactory in a jar file that exists in the WEB-INF/lib directory. I have the appropriate ejb-ref element in my web.xml file:


    And since we are deploying on Weblogic 6.1, the appropriate piece in the weblogic.xml:


    When I see the web application load up in the Weblogic server log, it is correctly associated with the ejb-ref with the jndi-name, but at runtime when my EJBHomeFactory looks up the class, the association is not made. I have some discretion over the JNDI names so for now I have made the JNDI name the same as the full name of the EJBHome and everythings works that way, but I want the more elegant solution to work.

    Do you have any ideas? Is there something about the container that needs to be configured? When you said the HomeFactory needs to be in WEB-INF/lib did you mean WEB-INF/classes?