News: Optimizing Entity Beans java live chat transcript available

  1. The chat transcript from the java live session 'Optimizing Entity Beans' is now available. Akara Sucharitakul, author of the 'Seven Rules for Optimizing Entity Beans' article answered some tough questions on entity beans.

    My favourite is the age old: "Do you think that distributing a cache of entity beans across servers in a cluster is a good optimization?"

    Read Optimizing Entity Beans Chat Transcript.
  2. Hi All-

    I would just like to point out an addendum to the transcript. The speaker shows his reluctance for 2PC because he is concerned of a performance slow down. I believe that this is a non-issue. Any transaction manager worth it's salt will know how many resource managers are participating in the transaction. If all of the resources are driven by a single driver or there is only a single resource, a good transaction manager will automatically optimize the transaction to be a 1PC instead of a 2PC. This happens transparently.

    ALWAYS make sure that your application server provider does this optimization. Not many TXs need to be 2PC -- only when multiple resource managers are involved.

  3. I am a little bit confused by Akara's comment on BMP vs CMP performance wise. Is he saying that without good BMP optimitzation, CMP is 2-3X faster than BMP. And even comparing to very well optimized BMP, CMP could still be 0 ~ 50% faster than BMP? Anybody who have real project experience can back up his claim? I have a client writing a lot of Oracle Stored Procedure inside BMP, and they think it will perform faster than CMP, I don't have time to sit down to prove they are wrong or right. Any comments?

    Jim Zhou.
  4. Hi Jim,

    The real issue with BMP is the following

    - The main way to get high performance BMP is to forego loading your database data into objects and to use stored procedures, as your client has done. While such an approach works, using stored procedures for complex business rules or row-at-a-time processing defeats the purpose of entity beans which are to encapsulate your rules for re-use and maintainability. PL/SQL can be a difficult language to pull apart due to its lack of polymorphism (though this changes in Oracle 9i, but it's a VERY new feature).

    - CMP finders will always be faster than BMP finders since they can query the entire resultset (unless you use fat keys)

    - Assuming one WILL populate its data into objects in the BMP entity bean for the current transaction, then the BMP implementation will have ensure there are "dirty flags" and/or "change trackings" for which fields have changed to determine the most optimal SQL update statement on ejbStore(). Another problem is to create a customized policy for "lazy loading" or "faulting" data into memory when a piece of the business model is accessed. With BMP this requires overriding or composing the existing Java collections classes, itself a tedious task -- and also requires careful designing of appropriate isolation levels so that lazy-loaded data is consistent with pre-loaded date.

    In CMP, the above must still be done, but usually with a framework that does the dirty work for you and/or configuration tools to determine what should be lazy loaded, and what should be pre-loaded.

    Hope this gives you the picture... it's two different angles: if you view entity beans as wrappers for stored procs, then CMP has little benefit. But if you view entity beans as wrappers for your business domain model, CMP is quite necessary.

  5. Hi Akara,

    Could you tell us which app servers you tested against? In my limited experience (iPlanet 6, WebLogic 5.1, WebSphere 3.5) BMP has always out performed CMP. I expect this to change with the wide spread adoption EJB2, but not until then. Could you also tell us what you tested specifically.

  6. Hi all,
    I found the chat interesting, but I 'm sorry I missed the opportunity to ask the ONE question that I cannot seem to get a clear answer on: Our target application type is large enterprise (100+ users, 100+ tables). I have read/heard several recommendations to not create one Entity Bean for each table, because of the overhead/performance, etc, but to rather use a "coarse grained" approach. My question is simply how do you go about deciding which tables should get Entity Beans and which ones not? And how do you handle the tables that didn't get Entity Beans? And what is the cutoff point: is 20 Entity Beans OK, but 100 is not?
    Any answers/pointers would be greatly appreciated!

  7. Creating fine-grained beans is allowable under two circumstances:

    - you're using a fairly sophisticated CMP implementation
    - your container supports local EJB objects (i.e. non-RMI)

    Naturally such a solution isn't generally recommended because it depends on server-specific features, but with EJB 1.1 CMP this is reality.

    Persistence PowerTier, Borland AppServer both have good CMP implementations. TopLink is probably the most sophisticated, with CocoBase being close (or better according to some). PowerTier in particular is very sophisticated with a persistent cache built in.