How to avoid database trips for every method call in CMP


EJB design: How to avoid database trips for every method call in CMP

  1. How to avoid database trips for every method call in CMP (2 messages)

    The EJB container reads the latest data from the database for every business method call to the CMP Entity bean. This will severely degrade the performance as database is consulted for every operation.

    If database trip is made for every business method invocation then what is use of Caching entity beans?

    Can we avoid unnecessary trips to database in CMP?

  2. Hi,
      As per the EJB spec. the container calls ejbLoad() at the begining of every transaction, and calls ejbStore() at the end of every transaction.

      There r many ways of optimising on the number of data base hits. Most of which r vendor dependent.

      With weblogic u can optimise the ejbLoad() calls as well as the ejbStore() calls.

      optimising ejbLoad() calls :-
      1. u can make is_db_shared = false, which reduces the unnecessary ejbLoad() calls, in case ur entity bean is the only gateway for modifying ur database.

      optimising ejbStore() calls :-
      1. use is_modified_method_name, which writes to the database only if the fields in the entity bean are modified.
      2. use read_only cache strategy if ur entity bean is used only for reading data.
      3. use read_mostly design pattern, if ur entity bean has a large number of reads and comparitively less number of writes.

    Manohar(manoharm at planetasia dot com)
  3. In general, as Manohar posted, you should do the following:
    *) Wrap with session beans: This reduces the number of transactions (if the transaction attribute of the business method is not set to REQUIRES_NEW, but this is nearly never the case). In fact, the container doesn't make one database roundtrip per method but per transaction.
    *) As already said, you can tell nearly all containers that they have exclusive access to the DB. This means: no DB accesses for read methods if the EB is in the cache. Especially with Borlands AppServer this gives you a great performance advantage.
    *) Probably your design doesn't wrap EBs with SBs, bcause if it would, you probably wouldn't have encountered these problems. Now there are two "simple" ways to solve this. Either use client demarcated transactions (which have inherent problems, so I wouldn't choose this method) or use "value objects", i.e. make a new serializable object, put all properties of the EB in it and use it as get/set return value/parameter. Thus if you are updating/reading many attributes at once this means only one transaction and only one remote call.
    *) Do NOT try to cache yourself. Unless your appserver is a really bad one it will know what it is doing and be faster than your methods. Only in some cases you should implement your own cache.
    *) One method to reduce general load on the database is making your EBs more fine-grained, but this has other disadvantages (see the "coarse grained vs. fine grained EBs" discussion). You should carefully consider the tradeoffs against each other, you will have more DB-roundtrips but smaller packets. If you are using EJB 2.0 (guess you don't) you can use dependent objects.