question about CMP 2.0's column mapping

Discussions

EJB programming & troubleshooting: question about CMP 2.0's column mapping

  1. question about CMP 2.0's column mapping (8 messages)

    Hi All

    Highly appreciated somebody can help me on below question

    let's a "orderitem" table has a foreign key column called "product_id". Naturally, in CMP 2.0, a relationship will be defined and map to column to below setter/getter methods.

    setProduct(Product p);
    Product getProduct();

    I feel that doing so may incur kind of overhead because if i want to call "setter" to change "product_id", i have to load entity bean, Product first before calling the "setter".

    Is it possible to map the "product_id" column to 2 pairs of setter / getter methods such as follows ?

    setProductId(int p);
    int getProductId();
    setProduct(Product p);
    Product getProduct();

    so that i can choose to use either pair of setter / getter as appropriate. If not so, highly appreciated one can offer me some insight in how to make decision on this issue.

    regards
    dso

    Threaded Messages (8)

  2. The Product EB can be eagerly loaded by CMP engine, 1 query for both orderitem and product EBs. Check the vendor docs for relationship caching

    Mike
  3. feedback on "eager" loading[ Go to top ]

    If "eager loading" approach is used, will it end up with cycling loading ?(A load B, B load C, C load A). Mostly importantly, based upon my e.g., if i want o update the "product_id" column of order_item, i need to load "Product" entity bean and then call "orderitem.setProduct" instead of "orderitem.setProductId". It sounds quite ineffective because updating orderitem would lead to unneccessarily loading of "product". Any advice on this issue ??


    regards
    dso
  4. Caching[ Go to top ]

    Hi Dan,

    I do not aware of any EJB Container provider supports setting relationship by primary key directly. Loading of a local EJB by primary key can be very fast if the container support caching. The loading operation can avoid querying the database and is an in-memmory operation if the bean was loaded in the cache. Check your container provider for their support of caching.

    Steven Vo
  5. Hi Steven

    thank u very much for your feedback. However, i can't fully perceive what the "cache" u mean in your reply. Taking the question i posted as an e.g., do u mean that
    as the order item is loaded, its associated "product" will be eagerly loaded ?

    Would u mind further elaborate below statements in your reply ?

    "I do not aware of any EJB Container provider supports setting relationship by primary key directly."

    [Taking my e.g. of "order item & product", the order item table should have a "product_id" foreign key column which refer to the "id" primary key column of product table. Hence relationship is setup involving a primary key ]

    "Loading of a local EJB by primary key can be very fast if the container support caching."

    [is the "caching" u are talking above referring the commit option A ? If not so, are u taking a cache layer technology in-between the app server and db server ? ]

    thank you a lot in advance.

    dso
  6. Selectively use Entity Bean[ Go to top ]

    Entity Bean model was not clearly thought out from the beginning, evidenced by big changes from 1.x to 2.0. 2.0 has smart idea but still does not fully address the basic model. That's why you often need to depend on vendor's features to walk around the lackness of specification.

    The performance penalty is expected and is normally tolerable (in your case also). Because the CMP persisting classes are generated, vendor can normally figure out a sql to early loading a relationship, instead of retrieving beans separately. Of course you don't want it to early load all relationships, normally you can specify which relationship to early load.
  7. Hi Dan,

    [i can't fully perceive what the "cache" u mean in your reply. Taking the question i posted as an e.g., do u mean that
    as the order item is loaded, its associated "product" will be eagerly loaded ?]

    What I meant by caching is the container provides a cache for entity beans based one their type, primary key (PK). When the bean is first loaded, the container will query the database for its info and put the bean in the cache. The second load of bean with same primary key just return the bean from the cache without costly going to the database. An in-memory operation of loading a bean form the cache is very fast. IMO, loading a bean with caching is very fast if the bean has bean loaded in the cache. In your scenario, the product item probably already be loaded in the cache since you have.

    Regarding your “eagerly” loaded example, it is the optional feature of CMP provider and the provider must resolves cyclic loading as you have described. Some call this feature, batch reading or joining. Oracle has a TopLink product that supports this feature. TopLink has a CMP ith Oracle 9iAs, WebLogic and WebSphere, TopLink can traverse multiple relationships for “eagerly” load. E.g., order -> product -> manufacturer, loading the order item also loads its associates (product and manufacturer) in on query.

    Your idea of having a set[Relationship]Id method on the abstract class such that the container will update the FK. This is not part of the EJB spec so no CMP 2.x provider currently has this optional feature to my knowledge. If caching feature is supported as I described, this feature is not necessary IMO.

    I hope this help.

    Steven
  8. further question about caching in CMP[ Go to top ]

    Hi Steven

    Thank u so much for your detailed explanation. Regarding your below explanation about the senario of CMP caching, as far as i know, if the commit-option is set to A, what mentioned below is true. However, if the commit-option is set to B / C which should be the default one adopted by some app server because usually db is not exclusively access by j2ee app server only, in this case, 2nd load of bean (in another transaction) will lead to invocation of ejbLoad and ejbStore. CMP will be synchronized with db. Hence, caching would no longer happens. Am i correct ?

    [extract from your last reply]
    "When the bean is first loaded, the container will query the database for its info and put the bean in the cache. The second load of bean with same primary key just return the bean from the cache without costly going to the database"

    Once again, thank u very much for your sincere reply and hope u can once again share with me about your thought in my question.

    dso
  9. further question about caching in CMP[ Go to top ]

    Dan,

    [if the commit-option is set to B / C which should be the default one adopted by some app server because usually db is not exclusively access by j2ee app server only, in this case, 2nd load of bean (in another transaction) will lead to invocation of ejbLoad and ejbStore. CMP will be synchronized with db. Hence, caching would no longer happens. Am i correct ?]

    Caching is still possible with commit-option B/C. In option B, the caching can still be support through optimistic concurrency control strategies to synchronize the instance’s state from the persistent storage. The implementation can combines optimistic locking and refreshing to implement such strategy. The container must refreshes the cache instance from db when the locking detects the instance’s record in db was modified by another application.

    Steven