Discussions

News: Article: Writing Performant EJB Beans in Java EE with Annotations

Bookmark and Share Get thread feed

  1. Article: Writing Performant EJB Beans in Java EE with Annotations (15 messages)

    In "Writing Performant EJB Beans in the Java EE 5 Platform (EJB 3.0) Using Annotations," Scott Oaks, Eileen Loh, and Rahul Biswas look at performance in three broad areas: developer performance, performance of 3.0 session and message-driven beans, and performance of Java technology persistent entities. Editor's note: "performant" is a noun, meaning "a performer," or "one who performs," and thus isn't really correctly used as an adjective. But we all know what it means, right? That is, we all know it means "having the characteristic of performing well." One interesting discovery is that JavaEE does not carry a negative performance impact, a good sign for such a big change in persistence and methodology. The article also goes into use cases for JPA, showing what entity models and accesses work well vs. which ones are likely to yield bad performance. One thing the article does not do is show configuration of the application server by annotation, although they do mention a few things. For example, FetchType.EAGER is required to be handled as an eager fetch by the container, whereas FetchType.LAZY is merely a suggestion (in other words, the container can still eagerly fetch the data.) They also mention configuring the cache for JPA, but since caching for the various JPA implementations isn't standard, there's no way they can actually show the caching being implemented - which would have made the article far more useful. What do you think?
    Reply to this

    Threaded Messages (15)

  2. Re: Article: Writing Performant EJB Beans in Java EE with Annota[ Go to top ]

    Yes, I agree that JPA and Annotations are great advances for the Development of the Persistence-Layer - independently with location inside or outside of the EJB-Container. Today existing implementations of the JPA-Standard are very great, but in some cases existing difficulties with few implementation details - which are in most cases from secondary importance and normally fixed soon. The integration of an object-oriented Persistence-Layer needs generally a well-wrought Design of the Object-Hierarchy and also a flexible Strategy for an encapsulated Access from the Presentation-Layer, ... which enables the Handling of Lazy-Load and other important details in an efficient, sure and solid manner. Sorry for my English ... Roland SOA Kompetenznetzwerk
    Reply to this Reply to original

  3. JPA caching in Toplink Essentials[ Go to top ]

    I saw a very useful article about caching in Toplink Essentials JPA implementation in Wonseok Kim's blog: http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t_1.html I think some similar things exist in Hibernate JPA implementation.
    Reply to this Reply to original

  4. Re: JPA caching in Toplink Essentials[ Go to top ]

    I saw a very useful article about caching in Toplink Essentials JPA implementation in Wonseok Kim's blog:
    http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t_1.html

    I think some similar things exist in Hibernate JPA implementation.
    True. There are a number of excellent references for each JPA implementation. However, a single article covering JPA as a specification wouldn't have been able to show these in action without ignoring a significant portion of their audience... unless they wanted to replicate the configuration details three or four or five times. :)
    Reply to this Reply to original

  5. Performant is a noun, not an adjective.[ Go to top ]

    http://dictionary.reference.com/browse/performant "One who performs", like an "informant", one who informs. I've heard lots of people in the computer industry use it as an adjective while trying to sound smart, and I find it really funny. Also, "EJB Beans" is redundant.
    Reply to this Reply to original

  6. Re: Performant is a noun, not an adjective.[ Go to top ]

    "One who performs", like an "informant", one who informs.
    informative -> providing information performative -> providing performance
    Reply to this Reply to original

  7. Re: performative[ Go to top ]

    Actually, performative doesn't mean "provides performance" it describes "an utterance that performs an act" such as "I now pronounce you man and wife" or saying "I promise". http://dictionary.reference.com/browse/performative English is ridiculously idiomatic.... And of course there are lots of words that are multiple parts of speech simultaneously... take "Google" for example... it's a noun, a proper noun and a verb. Given how frequently I've heard Performant used as an adjective, and considering that most people get it, I'm prepared to accept Performant as such. Somebody call Merriam-Webster.
    Reply to this Reply to original

  8. Re: Performant is a noun, not an adjective.[ Go to top ]

    I've heard lots of people in the computer industry use it as an adjective while trying to sound smart, and I find it really funny.
    Exactly. How hard is it to say "efficient" ?
    Reply to this Reply to original

  9. More on EJB3 performance[ Go to top ]

    I blogged a few weeks ago about my experience with EJB3 using Oracle as a back end database. There were some additional factors that we encountered that dramatically impacted performance. Namely, if you're faced with use cases where large numbers of records need to be inserted in a single transaction, the EJB3 spec can sputter to a crawl. The issue is due to how EntityManager.persist invocations require two queries to actually persist entities under Oracle. One call is required to query a sequence for an ID, the second is to actually perform the insert. I've outlined this issue, along with some other suggestions that I feel would benefit the spec in my blog: http://tapestryofthoughts.blogspot.com/2006/08/ejb3-wishlist.html
    Reply to this Reply to original

  10. Re: More on EJB3 performance[ Go to top ]

    One call is required to query a sequence for an ID, the second is to actually perform the insert.
    Any sane ORM tool would allow the user to grab a cache of sequence values from the first call and then it would have them in-memory for subsequent objects that are needed, so you get 2 SQL for the first object and 1 for each subsequent one til the cache is used. No specification states that you must make 2 calls, that is down to the implementation.
    Reply to this Reply to original

  11. Re: More on EJB3 performance[ Go to top ]

    I blogged a few weeks ago about my experience with EJB3 using Oracle as a back end database....if you're faced with use cases where large numbers of records need to be inserted in a single transaction, the EJB3 spec can sputter to a crawl.
    FWIW...If you're using EntityManager and working with persistence, it's technically the JPA spec you're using, not EJB3. The persistence chapter of the EJB3 spec is one page, saying essentially "See the JPA spec." :)
    Reply to this Reply to original

  12. Re: More on EJB3 performance[ Go to top ]

    Namely, if you're faced with use cases where large numbers of records need to be inserted in a single transaction, the EJB3 spec can sputter to a crawl.
    Released specs don't sputter to a crawl (although some of them do during development, and a few come to mind... ;-). Released specs are frozen in time. Your application might be crawling, but that is actually a problem with the way it is configured.
    The issue is due to how EntityManager.persist invocations require two queries to actually persist entities under Oracle. One call is required to query a sequence for an ID, the second is to actually perform the insert.

    I've outlined this issue, along with some other suggestions that I feel would benefit the spec in my blog:

    http://tapestryofthoughts.blogspot.com/2006/08/ejb3-wishlist.html
    The spec already does offer something to solve this problem. Take a look at @SequenceGenerator.allocationSize(). It allows you to preallocate batches of sequence numbers to use for insertion. Oracle supports this both at the TopLink Essentials JPA implementation level and in the database so it will work regardless of the JPA provider you are using, as long as it is compliant. -Mike
    Reply to this Reply to original

  13. Nit Picks[ Go to top ]

    OK, let me rephrase: Namely, if you're faced with use cases where large numbers of records need to be inserted in a single transaction, the EJB3 implementation on JBoss 4.0.4GA can sputter to a halt. Is that better? ;) Actually, the correction is merited. It's not the designers of the specification that should be held directly to account. But then again, assuming that an issue like this be left up to implementation is a bit shortsighted.
    Reply to this Reply to original

  14. Re: Nit Picks[ Go to top ]

    OK, let me rephrase:

    Namely, if you're faced with use cases where large numbers of records need to be inserted in a single transaction, the EJB3 implementation on JBoss 4.0.4GA can sputter to a halt.

    Is that better? ;)

    Actually, the correction is merited. It's not the designers of the specification that should be held directly to account. But then again, assuming that an issue like this be left up to implementation is a bit shortsighted.
    Julien, I'm not sure you caught the last part of my post. I was explaining how we solved this exact problem in the specification by adding the allocationSize() field. Either you are not setting it properly or it is not working correctly in the implementation you are using. If you are not setting it then it defaults to 50 so you should only see one sequence allocation SQL statement for each 50 inserts. -Mike
    Reply to this Reply to original

  15. Re: Performant is a noun, not an adjective.[ Go to top ]

    Vocabulary is always evolving. When sufficiently many people use a word to mean something, that IS a valid use of the word. Part of the work of lexicographers compiling dictionaries is to document such new words, or new usages. Therefore, the fact that "performant" is so far not an adjective in the dictionary just means that the specific dictionary has to catch-up with what has become quite common usage within software communities. The linguistic smugness of the original poster, and his amusement, is uncalled for.
    Reply to this Reply to original

  16. Re: Performant is a noun, not an adjective.[ Go to top ]

    http://dictionary.reference.com/browse/performant
    Performant: Sounds like a build tool to me :)
    Reply to this Reply to original