Finder Method Discussion

Discussions

EJB design: Finder Method Discussion

  1. Finder Method Discussion (7 messages)

    I have an EJB called Product. I need to find all product of a certain category.

    1) One approach is to do code a finder method with the category code as an input on the EJBHome interface of the Product, which returns an enumeration of all Product interfaces:

      Enumeration findByCategory(String categoryCode);

    The problem I forsee is that if 1000 products are returned, I would have 1000 EJB instances on the EJB container.

    2) The other approach is to use a Session bean and get just the primary keys of all products in a Vector and then call findByPrimaryKey on the Project's EJBHome interface.

      Vector getAllProducts(String categoryCode);

    This would be 1 call to get all the IDs and another call to get the Product remote interface.

    Which is better?

    Threaded Messages (7)

  2. Finder Method Discussion[ Go to top ]

    Approach #1 shouldn't return an enumeration of Product interfaces. It should return an enumeration of Product primary key instances, perhaps encapsulated in a class called ProductPK. The caller of the finder method would then call findByPrimaryKey for each entity that he really wants to retrieve.

    Of course, if you have to retrieve *all* of the entities in a large result set then you'll get much more efficiency from a session bean that can retrieve all database rows in one SELECT statement as opposed to one SELECT per row.

    This latter approach is the one that I typically use.
  3. Finder Method Discussion[ Go to top ]

    The method, ejbFindByXXX always returns either a remote, or a collection of objects that implement the remote. See Section 8.3.2 of the EJB 1.1 spec.

    As to which is better, will you ever be using just some of the remotes? If not, doing it in one call is probably better. Think of the bandwidth issue - you make a call from your client, and a collection of remotes is serialized back. Or you make a call, and a group of <primary key> objects are serialized back to the client, which are then serialized back to the server, automagically turned into a remote, and serialized back to the client.

    If you are going to cull out some of the primary keys, and only do a findByPrimaryKey on those selected primary keys, then returning a list of primary keys might be more advantageous.

    As always, business logic will make the decision for you...

    David.
  4. Finder Method Discussion[ Go to top ]

    I am just worried about scalability if the server has to create many server-side EJBs.
  5. Finder Method Discussion[ Go to top ]

    I am just worried about scalability if the server has to create many server-side EJBs. <

    There's no substitute for hard facts. You should run some benchmarks to see how the various options hold up in *your* situation. Don't guess.
  6. Finder Method Discussion[ Go to top ]

    Benedict,

    You need to benchmark it and see whether it is expensive or not.

    Now personally I find multi-bean finders a poor design pattern. What I prefer is to query via a session bean and then to update/insert via the entity beans.

    Just my personal preference.


    Dave Wolf
    Internet Applications Division
    Sybase
  7. Finder Method Discussion[ Go to top ]

    The method, ejbFindByXXX always returns either a remote, or a collection of objects that implement the remote. See Section 8.3.2 of the EJB 1.1 spec.<

    I think we're confusing remote interface definition with method implementation. A multi-object finder method is defined to return a collection -- and the remote semantics specify that the collection will contain instances of the entity bean's remote interface.

    But the implementation of a multi-object finder method, e.g. ejbFindByXXX, must return a collection of primary keys. See section 9.1.8.2 of EJB 1.1 or section 9.6.6.2 of EJB 2.0.
  8. Finder Method Discussion[ Go to top ]

    Sorry - you're right. The ejbFindByXXX returns primary keys, and the container intercepts, instantiates classes that implement the remote, and return those classes as part of a collection.

    Missed the "ejb" prefix, which is all important.

    David.