Discussions

News: JDC: Seven Rules for Optimizing Entity Beans

Bookmark and Share Get thread feed

  1. JDC: Seven Rules for Optimizing Entity Beans (6 messages)

    • Posted by: Dion Almaer
    • Posted on: May 23 2001 22:41 EDT
    The Java Developer Connection posts:

       Explore these seven rules to get the best performance from your entity beans, and find out how you can really "write once, run everywhere" effectively.

    Entity beans provide a clear model to represent persistent business objects in applications and their design. In object models, simple JavaTM objects are normally represented in a straightforward way, but do not include the transactional persistence management functionality usually required for business objects. Entity beans not only allow the same type of modelling and thinking about business objects in an object model, but they also encapsulate persistence mechanisms while hiding all complexity behind the bean and container services. This allows applications to manipulate them as Java object references. By hiding the persistent form and persistence mechanism from any calling code, entity beans allow for creative persistence optimizations by the container, while keeping the data store open and flexible, only to be determined at deployment time.


    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules
    Reply to this

    Threaded Messages (6)

  2. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    I always have the following question:

    On the one hand, they tell you to use coarse-grained entity beans, which to me means your have to use BMP because of the EJB 1.1 CMP limitations, but on the other hand they also say use CMP whenever you can. How do people reconcile the two seemingly conflicting pieces of advice?
    Reply to this Reply to original

  3. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    Why would coarse grained entity beans force you to use BMP. Surely all that is mean by coarse grained is that you make less calls across the network to get data from you bean. That is, you have one method in the remote interface that returns all the data you require in one hit. You can still do this with a CMP bean.
    Reply to this Reply to original

  4. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    To me coarse-grained entity beans do not simply mean the use of value objects for get and set. My understanding is that it really means that when you have a master-detail relationship, model the master as the entity bean, and the details as a collection of dependent objects in the entity bean. One example is when you have Order and LineItems, model the Order as the entity bean and LineItems as an ArrayList of regular Java classes, which is a member of the entity bean. How do you use CMP under this scenario?
    Reply to this Reply to original

  5. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    I, however, wouldn't recommend to do "all too coarse grained" entity beans, because:
    *) They are not always faster, because the container has to load their whole state (and if they are coarse grained, they normally have some serialized objects) although it may never be used! Although I agree and wouldn't make an address attribute of a person an entity bean (an often used example) if there is no need to search for it often, so the truth may be in between.
    *) Network calls are not as expensive as most people think, because all application servers I know use a "pass by reference" and optimize local calls. And the most expensive thing in EJB calls is marshalling/unmarshalling, which is often nothing else than serializing/deserializing (or something similar, if the vendor chooses to replace java serialization, it should at least be faster!). This is exactly what happens often in coarse grained EBs.
    *) If you now begin to develop an EJB application, chances are you'll be able to deploy on 2.0 persistence. Well, use "fine grained" (see above, not "too fine grained") EBs, because you'll only have to replace the remote with a local interface; "Pass by reference" should also be expected, as most containers do this by default.

    There is a thread about this on TSS, but I do not remember where exactly.

    kind regards,

    Messi
    Reply to this Reply to original

  6. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    I like the approach you take. Then my question becomes, how do you decide an entity bean is "coarse" enough? Let's say in the database we have a parent-child-grand child relationship. Should the parent or the child become an entity bean? Do you have a general rule which says if a findByParentId method returns more than 100 elements in the Collection, I'd better start to use entity beans at the child level; otherwise the number of grand children will get out of hand?
    Reply to this Reply to original

  7. JDC: Seven Rules for Optimizing Entity Beans[ Go to top ]

    Hmm, this is more "by feeling" (I know this is not the development process as it "should be", but hey... I believe software develpmemnt is more than just a process). There are however, some rules of thumb I use:
    *) Do I need to search for an attribute of the object in question? If yes, this is a strong hint to be an entity bean (I dislike the "manual dependent object" approach by simply using SQL). Although most appservers allow to say "WHERE myEJB.myObject.someString LIKE %hello%" consider how fast this will be.
    *) How many complex attributes does it have? I try to avoid complex-complex attrbiutes (i.e. an object which has an object which again has an object). So the "grandparent" will never be an EB.
    *) How much (de)serialization does occur? i.e. how "big" in bytes is the object and how much of the attributes do I need? If I have an object where I need 5 simple attributes and it has one complex one with about 1 Meg of size (say, an image) I would try to put the image somewhere else if I need the simple attributes often. I would say if the appserver in most cases only needs 1/5 or less of the loaded data consider separating the objects, especially if this object is used often.
    *) So called "remote calls" are to be avoided, of course, especially from the client. Just do not waste too much time on this, remote calls are much faster than you think. This topic has been emphasized too much. Every appserver written by someone else than beginners (I appreciate Borland's technology here... they definitely have the cracks there) will use pass-by-reference, if you set transaction levels to "required" there is nearly no overhead etc. I mean of course these calls are expensive, but they are there to be used, to take profit. And if you avoid these calls by putting everything in one EB you'll definitely have a slow system... and an unextensible one!

    In general I'd say (as bottom line): Just do your design, consider which objects should be persistent, and then group them. This will be quite easy, as it (like always with OOA/OOD) comes "automagically" if you just keep doing OO.
    I'll maybe develop a lighweight process/methodology on finding EBs and dependent objects, but I'd like to know who would be intrested in such a thing? Give me some feedback, and I'll think about it.

    kind regards

    Messi
    Reply to this Reply to original