EJB design: JDBC via session bean performance vs. queries via entity beans
There has been much debate about this topic, but I would like to question the actual performance differences, particularly since Inprise and BEA both provide app. server's with the concept of a read-only bean.
- Posted by: Floyd Marinescu
- Posted on: May 18 2000 16:06 EDT
The argument in favour of JDBC vs. session beans rests on the fact that the Database is good at caching, and that the alternative (via entity beans) involves the extra overhead of transactions, etc.
However, using read-only beans, entity bean state is stored in memory, like an "in-memory database". Wouldn't it be faster to query data by simply traversing object references in-memory? The alternative (JDBC via session beans) requires the extra overhead of database communication for loading data that has not changed.
What do you guys think?
- Re: JDBC via session bean performance vs. queries via entity bea by Timothy Fry on May 18 2000 17:25 EDT
- vendor dependent by Stu Charlton on May 19 2000 22:20 EDT
entity beans, a step in the right direction by Floyd Marinescu on May 23 2000 11:10 EDT
- Entity beans in spec by Stu Charlton on May 23 2000 04:16 EDT
Optimised way of specifying isModified and isDBShared by Kokwai Wong on June 04 2000 10:56 EDT
- Optimised way of specifying isModified and isDBShared by Floyd Marinescu on June 12 2000 05:00 EDT
- entity beans, a step in the right direction by Floyd Marinescu on May 23 2000 11:10 EDT
- Re: JDBC via session bean performance vs. queries via entity bea by Gregory Peres on May 19 2000 22:25 EDT
- vendor dependent by Stu Charlton on May 19 2000 22:20 EDT
- Interesting by Greg Paley on October 29 2007 11:07 EDT
However, using read-only beans, entity bean state is stored in memory,
>like an "in-memory database". Wouldn't it be faster to query data by
>simply traversing object references in-memory? The alternative (JDBC
>via session beans) requires the extra overhead of database
>communication for loading data that has not changed.
>What do you guys think?
I imagine that your choice of mechanisms would be based largely on the
nature of the data you are accessing: for smallish quantities of
easily indexable and fairly static data that is read far more often
than it is written, there is no question that reading it from an
in-memory object graph via a session bean for example, would be far
faster than continually reloading it from an RDBMS with JDBC. This
approach would probably not be suitable for other types of data
though, e.g., entity-type data that is changed as part of a
In any event, judging by the mutterings and head-shaking from the
various EJB vendors when you suggest using Entity Beans for anything
other than trivial applications, their usefulness is limited and their
very existence seems to be little more than a sop to RDBMS vendors'
demands for easy access to rows in tables.
tim at calsoftech dot com
The problem with entity beans right now is that their performance profile is very dependant on container+server implementation. One can't expect to get good performance out of naively implementing the equivalent of SQL row updates for ejbLoad() and ejbStore(). There has to be object graph and attribute change tracking in the server to allow for a decent cache to accumulate.
I find that my experience is somewhat mixed compared to Tim's. There are lots of vendors who mutter about how entity beans are nothing but toys for now. And in general, I think I would agree. However a product like Persistence has very high performance container managed persistence, and one can easily write a high performance framework to do BMP with Gemstone's object database.
I hear that BEA Weblogic 5.1 has an updated CMP implementation. Any news on its quality?
I guess the problem is that entity beans don't actually solve the problem of scalable object persistence. It's just a very crude interface into what is actually a very hard and still somewhat open-ended problem. Entity beans still require a good underlying object to relational mapping framework (such as TOPLink or Persistence) to ensure you're not making zillions of SQL calls. They also could use a good transactional object cache like Gemstone's. Most vendors aren't ready or able to offer that level of service - plus the J2EE mantra seems to be to worship the specs but not hype any possibly proprietary API (however useful).
I'm actually looking forward to Apple WebObjects 5.0 .... finally a good o/r mapper underneath EJB.. woop!
I guess the problem is that entity beans don't actually
>solve the problem of scalable object persistence.
The theme in Java since the onset was to provide standard ways to tackle tough problems OR hide the problems behind API's, to simplify the jobs of the programmer. Entity beans are another example of this philosophy in action. Entity beans provide:
1) A standard way to persist your domain model
2) Encapsulation of domain model persistence mechanism
Your argument Stu, is that entity beans don't solve the scalable object persistence problem. I think your right on this one. The SPEC does not solve the problem, but as you have said, the vendor implementations do.
I think entity beans do a decent job in satisfying problems 1 and 2 (above), but should they really go all out to specify a solution to the scalable persistence problem? Right now, companies such as BEA and Inprise allow advanced middle-tier entity bean caching, simply by changing properites in the entity bean deployment descriptors. Infact, on TheServerSide.com, we have in effect build an in-memory entity bean database simply by setting isModified and isDBShared in the deployment descriptor. Does this lock my entity beans in with Weblogic? I don't think it does. No code has to be changed to move my beans from WL to EJBoss, just meta-data.
My point is that that over specifying entity beans could be counter productive. Right now entity beans solve the main problems they were designed to solve, and rely on vendor implentations to take care of the rest. If vendors can allow Entity beans to also solve the scalable object persistence problem simply by setting flags in a deployment descriptor, then I think that entity beans are a success.
You do have an interesting point in that it may be a bad thing for Entity beans to be over-specified. In this I agree from a business perspective especially -- it gives less room to innovate.
This does not change the observation that a specification that is influenced by implementation is often more useful than one designed in a vacuum. (this is otherwise known as iterative & incremental development).
Sun is in a difficult position on this one, so I sympathize. However, I also know that most vendors have not come up with an adequate black-box solution to the CMP problem so perhaps the answer is to specify hooks into fine-tuning the underlying persistence framework.
The unfortunate reality of the J2EE community is that currently the only way to fine tune CMP would be through a proprietary API and as we know there's a general aversion to exposing/using such an API (politically). So we're still stuck doing bean managed persistence.... I think the aversion to "anything not a Sun standard" has put innovation on the back burner. That is why I'm looking forward to Apple's entry into the EJB space.. they already have the crown jewel of object/relational mappers.
Can you share your implementation of isModified and isDBShared in Weblogic? Is it just a matter of always returning "false" and "true" respectively? How about the setting of number of instances in the cache? How much does this affect performance?
The implementation is pretty simple. Ues it is just a matter of setting "true" or "false" respectively.
In regards to the settings, we set timeouts of about 5 minutes (maybe we should make this longer) and instances of about 1000 beans (this is more than enough to cover all the messages that could appear on the front pages of this portal). Performance wise, this website is doing excellent. We have essentially created an in-memory entity bean cache, and response time never passed 1-2 seconds even under load.
"In any event, judging by the mutterings and head-shaking from the various EJB vendors when you suggest using Entity Beans for anything other than trivial applications, their usefulness is limited and their very existence seems to be little more than a sop to RDBMS vendors' demands for easy access to rows in tables. "
I am currently using GemStone/J and have built my own framework that exists inside the PCA (aka OODBMS) and I cannot see how I could retain the same flexibility in both design and quick time to market? Sure, I had to learn a bit of extra stuff, bang my head against my monitor a few times until I got it right but once you do... You can't go back.
I can traverse references in GemStone faster than light!... GemStone has so much under the hood that 90% of the development world doesn't even know about it is scary. M:M relationships RULE!
Having to build my own query-block-like framework was a bit of a tedious task but now that is done we are reaping the benefits!
I take it your not a fan of RDBMS and "flat" un-OO data driven models.
WebObjects has probably one of the best O/R mapping tools out there and frameworks. I wonder what they are going to have to drop(features) to support EJB.