TSS Takes "A Look Inside EJB For Architects"

Discussions

News: TSS Takes "A Look Inside EJB For Architects"

  1. TSS Takes "A Look Inside EJB For Architects" (7 messages)

    TheServerSide presents "A Look Inside EJB for Architects", a day by day glimpse into The Middleware Company's most advanced and 'prestigious' course. The first day of the course kicked off with an impassioned Q&A session on deciding upon EJB, J2EE vs. .NET, presentation layer frameworks, entity bean pro's and cons, project management and more.

    Everyone from seasoned J2EE developers to the J2EE savvy have descended upon downtown Chicago for this architectural pilgrimmage.

    Take a Look Inside EJB For Architects - Day 1.
  2. <quote>One of the main disadvantages with entity beans is performance as expressed by the 'n+1' problem. Whenever a client calls the get() method on an entity bean, the ejbLoad() method is automatically called, which results in a direct call to the database. Another problem with entity beans is that when a large number of rows are instantiated, an entity bean is created for each row and a stub is returned: imagine instantiating a million rows.</quote>

    I realize the article was not intended to be an exhaustive summary of the pro/con entity bean arguments, but I'd like to respond with a few thoughts anyway because I found this particular paragraph a little too 'absolute'. It's exactly the kind of reading some people may rely on if they are in a hurry to make up their minds on the merits of Entity Beans.

    1) n+1... Here's a quote from Tyler Jewel's article in v1/iss4 of Weblogic Developer's Journal p36. "EJB 2.0 solved this problem for CMP engines by requiring entity EJBs in a relationship to use local interfaces. [snip a couple lines] ... the CMP engine could continually optimize the n+1 scenario to be a 1+1 database hit scenario." I know weblogic can load the beans at the same time as the finder method executes, instead of revisiting each bean individually. Also - as mentioned in the article - entity beans are often cached. Hitting the cache means zero database calls (session beans & JDBC can also utilize caches - and 3rd party help is readily available, but to roll your own solution in a clustered environment is prohibitively complex if you have strict anti data aliasing requirements... I found out the hard way :-) ). The read-mostly pattern is quite useful in reducing chatter to the database. Although I'm only familiar with WLS, I'd be surprised if other servers don't offer similar optimizations.

    2) each getXXX() causes an ejbLoad(): true if you don't demarcate transactions (and if you're not interested in transactions for read operations, read-only beans are valuable) and you're missing the cache. My understanding is that ejbLoad will only be called when the bean begins to take part in a transaction, and won't be called again until the next transaction. It's not a minus in my books, when that's what you are trying to do! In a session bean->JDBC setup, if you wanted to make sure you had the true state of a field at the time you read its value you'd have to refresh your object within your code anyway. The longer you hold onto your session bean->JDBC objects, the less faith you have in the information they contain. With Entity Beans it's not a worry.

    3) large number of rows=large number of beans: I'm assuming this is being compared to having a session bean instantiate a large number of domain objects (one for each row's contents). I don't think either situation is particularly great. If a million (the article's number... not mine 8-) ) session bean->JDBC objects don't fit into your heap, what can you do except crash? With an EJB container I'd at least expect the passivation/activation capabilities to kick in and try to manage the situation.

    cheers,
    Markus
  3. Hi Markus, great comments. My own questions below:

    >>>CMP engine could continually optimize the n+1 scenario to be a 1+1 database hit scenario." I know weblogic can load the beans at the same time as the finder method executes, instead of revisiting each bean individually. Also - as mentioned in the article
     
       This sounds like a great feature, do you know how WL can be configured for this? Does it dynamically optimize its queries or something? In my book (EJB Design Patterns) I mention how advanced CMP implementations can address this issue through intelligent optimizations of the underlying JDBC calls. However, this is such a complex feature, I'd be surprised if any vendor other than WL/WS supported it, and the extent of their support.

       With regards to the point about ejbLoad, I think that if someone was using Session beans + JDBC, they wouldn't load the entire state of an object if they only needed 2 or 3 attributes, they would use JDBC and Custom DTO's, or perhaps Rowsets. Furthermore, they would bulkload all the rows they need in one call.

       Good point about the million rows.

    Floyd
  4. Hi Floyd... I love the way this site gives normal Joe's a chance to talk to the J2EE superstars :) Thanks for your response!

    Did a little digging, and the load on find functionality within WL CMP is controlled with a

    <finders-load-bean>true|false</finders-load-bean>

    tag inside weblogic-ejb-jar.xml (the wls specific ejb-jar.xml tag along). The docs say the value defaults to true.

    With regards to CMP containers... the nice thing is competition has really heated up and these will only get smarter/faster as time goes on. Your code can just come along for the ride... taking advantage of the competition. You'd have to think the containers with a close tie to particular databases will have interesting optimizations in the future / including the DB pushing into the app server's cache in circumstances where the App server does not have exclusive use of tables... I'm expecting some cool stuff from Oracle in the future (not holding my breath though :) ).

    With regards to not loading an object's entire state... it's worth pointing out that EJB 2 CMP also allows you to partition the fields within an object, for lazy loading of seldomly accessed sets of fields. Granted... this may be an open door for entropy to walk through :-), but it's interesting none-the-less.

    Also - in the case of data access objects (is DTO "data transfer object"?), ejbHome methods have access to ejbSelect statements. You could use these to hook into the EJB QL and create your custom objects. 2 big advantages I see with respect to this... #1... your CMP entity bean component, which you intended to be the source of truth for a specific part of the domain, can continue to be that authority... ie. you're not spreading persistence functions for a particular table around many beans. #2... With ejbSelect, there is no need to go behind the container's back! You can make use of all the caching and other optimizations that your vendor implements - for free!

    While I'm blabbing on here... another beef I hear quite a bit is that Entity Beans lock pessimistically. This is not necesarily the case... WLS actually defaults to locking through the DB, so you have the same isolation level that you would get if you included your JDBC calls inside a JTA aware connection. Again one ejbLoad()/transaction makes sence in this context.

    I share people's frustration in learning all the in's and out's of EJB 2.0 CMP entity beans. I have thrown manuals around the room and had to "go for walks" in getting the things up and runnning for the first time - but man-oh-man... once the initial investment is made does it ever pay back dividends. It is so cool to add a bean to a container managed relation collection and have the container handle everything for you!

    cheers,
    Markus
  5. Hi Markus,
     
      Thanks for the kind compliment. I built this site and love to stay in touch with its users. :)

       Weblogic is offering a major value add with its <finders-load-bean> tag, infact I told Linda DeMichael about the need for such a tag some time ago. Who knows, maybe it will end up in EJB 2.2. :)

    >>>close tie to particular databases will have interesting optimizations in the future / including the DB pushing into the app server's cache in circumstances where the App server does not have exclusive use of tables... I'm expecting some cool stuff from Oracle in the future (not holding my breath though :) ).

       That would amazing to have, and used to be possible. Oracle tried that (proprietary), but when they licensed Orion they decided to no longer put an EJB container in the database. I havn't heard anything out of Oracle about having such integration. Incidentally, there is an article on TSS. that talks about how to set that up yourself.


    >>>With regards to not loading an object's entire state... it's worth pointing out that EJB 2 CMP also allows you to partition the fields within an object, for lazy loading of seldomly accessed sets of fields. Granted... this may be an open door for entropy to walk through :-), but it's interesting none-the-less.

      I wasn't aware of that. Where in the spec is this mentioned? Do they allow you to define any extra info (like how a CMP engine should treat this 'block')?

    >>>Also - in the case of data access objects (is DTO "data transfer object"?), ejbHome methods have access to ejbSelect statements. You could use these to hook into the EJB QL and create your custom objects. 2 big advantages I

       Does EJB QL allow you to retrieve arbitrary sets of attributes (like OQL/SQL)? If not, then you would still have to load an entire EJB to extract a custom object no?

    >>>While I'm blabbing on here... another beef I hear quite a bit is that Entity Beans lock pessimistically. This

      Well said. Weblogic used to have this as the default and only option before 6.x, hence all the confusion.

    >>made does it ever pay back dividends. It is so cool to add a bean to a container managed relation collection and have the container handle everything for you!

       It is cool. My only remaining problem with EJB's is that they are still more heavyweight to develop than a plain java hierarchy - ala JDO. :)

    Floyd
  6. Floyd - sorry I ran out of time here... just a quick response. Partitioning of fields is indeed a standard part of the EJB 2.0 CMP spec.

    > Does EJB QL allow you to retrieve arbitrary sets of
    > attributes (like OQL/SQL)? If not, then you would still
    > have to load an entire EJB to extract a custom object no?

    Yes, ejbSelect allows you to access any of the container defined fields, and also you can take full advantage of the CMRs that have been defined! I know I'm repeating... but I think it is reasonable to expect that in many cases combining ejbSelect with a well managed cache and properly partitioned fields can whip the pants off sessionbean/JDBC setups.

    EJB 2.0 CMP Entity Beans may be more heavyweight than JDO... but when an investment is made in EJBs, developers are thinking their components are going to be around for a while. For this reason I think in many cases EJB 2.0 CMP is going to provide a better long-term return on that extra investment.

    Also look for the new generation of IDE's to significantly simplify these things as well.

    thanks!
    Markus
  7. <quote>
    >>>With regards to not loading an object's entire state... it's worth pointing out that EJB 2 CMP also allows you to partition the fields within an object, for lazy loading of seldomly accessed sets of fields. Granted... this may be an open door for entropy to walk through :-), but it's interesting none-the-less.

      I wasn't aware of that. Where in the spec is this mentioned? Do they allow you to define any extra info (like how a CMP engine should treat this 'block')?
    </quote>

    It's not really mentioned in the spec, but it is a direct consequence of the implementation of accessors being generated by the Persistence Manager (or whatever the new name is).

    WLS has the concept of "field groups", where you can declare a CM field to be part of a group. The fields are still lazy-loaded by default but on the first access, all the other fields in the group(s) the field belongs to are loaded as well (if you didn't define any group, the default is that all the other fields of the EJB will be loaded).

    --
    Cedric
  8. It's not really mentioned in the spec


    Well I'll stand corrected on that one :) When you work a lot with a specific container it gets a little blurry wrt what's possible in any container, and what's possible with the one you're using. Another example would be WLS's ORDERBY add-on (another common 2.0 beef) to the EJB query language, or I guess rather the <weblogic-ql>.

    Markus