How to decide which persistence technology to use? JDBC / CMP Entity Beans / Hibernate / JDO ?
Almost every web application today talks to a database and so at the start of each project, one question is surely going to come up. Which persistence technology to use?
I tried to google my way to the answer however either my google skills
are limited or the answer / a fair comparison of the available
technologies isn’t out there.
So I thought of making this blog
interactive. You post comments to this blog and state what you think is
for or against a particular technology. I will later compile all
suggestions into a tabular form. Keep your comments short so that they
can easily be placed in a tabular format.
Lets restrict the scope of the comparison to:
- JDBC
- Hibernate
- CMP Entity Beans
- JDO
Java persistence technologies. A comparison.between JDBC, Hibernate, CMP Beans and JDO
| JDBC | Hibernate | CMP Beans | JDO | |
|---|---|---|---|---|
| Plus | ||||
| 1 | Everyone knows it | Easy to learn | Ease of use | Vendor portable |
| 2 | Suited for small systems | Good performance | IDE support | Many vendors |
| 3 | Performance | JSR-220 (EJB3) persistence | Resume booster | Adopted by Apache |
| 4 | Stored procedure usage | Middlegen code generation | Middlegen code generation | Geronimo Integration |
| 5 |
Batch updates/inserts |
JDO vendors will support EJB 3 as well | ||
| 6 | Middlegen code generation | |||
| 7 | great help from vendors | |||
| Minus | ||||
| 1 | Not backed by specification | Heavy and complex | Low acceptance | |
| 2 | Have to learn on your own. Not enough help on forums | Steep learning curve |
Risky long term choice |
|
| 3 | Few credible vendors | |||
| 4 | ||||
| 5 | ||||
| Other comments and suggestions | ||||
| 1 | Prevayler (not listed) – Best if you are making a very small system (in terms of data size) that WILL NOT grow significantly and you dont’ need a RDBMS. Very easy to learn. Pure OO. Fast development. Excellent performance. | |||
| 2 |
What about IBatis? |
|||
| 3 | Forget the specs go with the best tool for the job. And there are way more tools then just hibernate. | |||
| 4 | I can’t say use this or that. Each has it’s advantages. Choose one and stick with it. | |||
| 5 | In the Torpedo benchmark, the top 2 performers are JDO implementations, beating out TOPLink, Weblogic CMP, and Hibernate. | |||
| 6 | Torpedo is a very useless benchmark. | |||
try going noob for a while and try getting free help on the hibernate forums.. try doing the same in a vendor forum og a place like jdocentral…
Its my experience that if you want to learn hibernate ..your on your own… your lucky if you get a reply in their forum.
I have had great help from people like robin ross, patrick linskey and other developers and also from users so it was easy to learn jdo.
jdo and hibernate are both great products when you learn them .. but you will probably learn jdo faster.
All the top O/R JDO vendors support batch updates/inserts too.
I believe hibernate supports batch updates/inserts.
‘Transparent EntityManager(PersistenceManager) management: EJB3’
Uh… only in a container. Just like you can do a PM injection with something like Spring in JDO. EJB3 hasn’t even defined how to get an EntityManager when you’re not in an appserver container! Not to mention the lifecycle of that EntityManager, such as whether it allows multithreaded access, or whether you can use it for multiple transactions, and what happens to all the persistent objects in between transactions… or anything about exception recovery.
?
‘Support for annotation-based metadata: EJB3’
True; I should have mentioned this one. I do hope JDO adds annotations in 2.x. I personally think code is absolutely the wrong place for mapping (column and table names in my code? why not use JDBC?!), but I’m sure some people will like using annotations for mapping better than XML.
?
‘A non-sucky query language: EJB3’
Complete matter of opinion. With JDO 2, JDOQL has become very powerful, and I like it a lot better than EJBQL. You don’t even have to learn anything to use it; it looks like Java code.
‘update/delete by query: EJB3’
JDO has delete by query. I already mentioned update by query in my first post.
?
‘Support for persistent properties (!): EJB3’
But no support for private persistent fields (!)
?
‘By the way, ‘Powerful eager data fetching’ and ‘Scrolling result set support’ are both also available in EJB3.’
No, they aren’t. I read the whole spec. There is a ‘fetch join’ concept, but it’s limited to queries only, and it can only fetch join one relation. Compare that to JDO 2’s fetch groups, which apply to any load and allow any combination of fields, relations, traversal depth specifications, etc. And there’s no support for scrolling results, because there’s no way to close a query result once you get it. Without an API to close the result, how do I clean up the cursor? I’m supposed to just hope the garbage collector kicks in in time to save my heavily-loaded application from running out of DB cursors?
‘And ‘Transparent identity/version tracking’ are useless features’
I consider not polluting my object model with crap properties that are only there to satisfy the persistence engine far from ‘useless’. But maybe that’s just me 🙂
I notice you didn’t bother to try to defend EJB3’s lack of support for Collections of simple values (like Collection) or its lack of Map support. Or the fact that JDO 2 has more flexible mapping.
In the end, though, I don’t think it matters much, since the JDO vendors all seem to be pledging support for both specs… even using both APIs concurrently with the same objects. That’ll be cool; people can just choose which one they like.
‘How can JDO have ‘many vendors’ but ‘low acceptance’? How would all those vendors survive if no one is using their products?’
Actually there are only two-and-a-half credible JDO vendors, and they are tiny.
‘Then try to tell me that EJB 3 has more persistence features than JDO 2 with a straight face.’
As far as I can tell, no-one ever claimed that EJB3 has *more* features than JDO2. Merely that it has *better* features. More features is not very useful if the features all suck 😉
Transparent EntityManager(PersistenceManager) management: EJB3
Support for annotation-based metadata: EJB3
A non-sucky query language: EJB3
update/delete by query: EJB3
Support for persistent properties (!): EJB3
By the way, ‘Powerful eager data fetching’ and ‘Scrolling result set support’ are both also available in EJB3.
And ‘Transparent identity/version tracking’ are useless features that create an absolute hard requirement that the implementation do buildtime bytecode processing. (It appears that the JDO EG screwed up, and did not realize this.)
How can JDO have ‘many vendors’ but ‘low acceptance’? How would all those vendors survive if no one is using their products?
I took a look at the published partial customer list of just one of the JDO vendors and saw names like eBay, Sun, US Army, 3M, The Gap, Motorola, Nokia, etc. I don’t think some random commenter crowing ‘low acceptance’ outweighs the evidence that JDO is doing A-OK in the commercial marketplace. Maybe it has low open-source acceptance, but I doubt that matters to the vendors 🙂
Also, how can JDO be a risky choice with so many vendors supporting it and so many big names using it and a new v2 spec that isn’t even final yet? Plus the JDO vendors pledging seamless interoperability with EJB 3…
Similarly, there are contradictions in the table for CMP. How can it have ‘ease of use’ but have a ‘steep learning curve’ and be ‘heavy and complex’?
Read the persistence part of the EJB 3 spec. Read the JDO 2 spec. Then try to tell me that EJB 3 has more persistence features than JDO 2 with a straight face. I’ve read both specs, and the conclusion is obvious.
Support for Map fields: JDO 2
Support for Collections fields of simple values: JDO 2
More flexible inheritance: JDO 2
Transparent identity tracking: JDO 2
Transparent optimistic versioning: JDO 2
L2 Cache management: JDO 2
Powerful eager data fetching: JDO 2
Scrolling result set support: JDO 2
That’s just some of the features JDO 2 has that EJB 3 doesn’t, and they seem pretty useful to me. The only EJB 3 feature I noticed that JDO 2 doesn’t have is update-by-query.
Plus, it seems like most of the JDO vendors are saying they’ll support EJB 3 interfaces as well.
P.S. It is just *not true* that JDO has more features than EJB3 persistence. They both have different feature sets, exposed to the user in different ways. Some features of JDO are not in EJB3 (‘cos we don’t think they are good/needed), some features of EJB3 are not in JDO.
Which feature set is more useful, and more aligned with the needs of enterprise computing is a matter of opinion, but IMO, EJB3 is a much better fit. Remember that ‘fewer useless features’ is itself a feature! A spec like this should be as simple as it can possibly be, while still solving all important problems for real applications.
Don’t believe the hype!
Regards,
Gavin
Hibernate can very easily get a top score in Torpedo, but I prefer not to give credibility and more attention to this broken benchmark. Please, actually take a look at what it does. It’s nonsense. I was going to blog about it, but decided not to, for the same reason – don’t give attention to silly things.
Regards,
Gavin
Use Hibernate – maintenance, ease of development ( use middlegen to generate most of the code, query by example, criteria is good fit for web apps)
When high performance is needed,
Use JDBC – performance, (batch updates/inserts or use of stored procedures )
Anybody care to enlighten me where is the URL to Torpedo ? :p
JDO will be developed to tightly integrate with Geronimo, Apache’s open source Java 2 Enterprise Edition implementation.
I have just updated the comparison table based solely on reader comments.
Please state specific Plus or Minus points in your comments.
And what is about IBatis?
Torpedo is a very useless benchmar.Every good ORM implementation (and there are about 5 at the moment) will get the top score easily.
Then why have only 2 ORM implementations gotten the top score? And why are the top 3 all JDO implementations? JDO’s enhancement strategy allows for some optimizations that other strategies simply can’t match.
That said, of course there’s a lot more to ORM than Torpedo. But I think top JDO implementations like the one that TheServerSide uses to power its site (see TSS’s ‘About’ page) also compete extremely well on overall feature set and mapping flexibility. Combine that with JDO’s vendor portability and the upcoming advances in JDO 2, and it makes for a compelling argument.
However, its not perfect.
I would never pick it to do batch processing. Its great for the web enviroment. However, I wish it had better ability to delegate an interceptor responsible for object deletion.
You might still find yourself writing sql/jdbc code.
In one of our systems, when we delete a task there is a bunch of stuff that needs to be cleaned up. If I were to make hibernate responsible(assoicate collections with cascade behavior) it would be way to slow in this case.
I can’t say use this or that. Each has it’s advantages. Choose one and stick with it.
I would prefer CMP, it’s easy to use if you have an IDE supporting your Applicationserver (I use WSAD for Websphere Development).
If wouldn’t have such tools, i think i’d use hibernate or jdo. jdbc is only an option if you want to optimize for performance.
Torpedo is a very useless benchmar.Every good ORM implementation (and there are about 5 at the moment) will get the top score easily. If one of the products hasn’t, its just because nobody really cares about another useless benchmark.
Torpedo only tests SQL generation for a handful of almost trivial cases (it improved significantly in the second version, but its still trivial), an area where ORM solutions are 99.99% perfect for more than a year. It’s not testing any relevant load performance or any other important feature.
The Public Final Draft of the JDO 2 specification was announced today (so much for it being a maintenance-only spec!). It is available now, and it has more features than EJB 3 persistence plans to have when it is finalized in 2006 (so much for JDO being ‘limited’). Apache just announced that it will host the JDO 2 API and TCK, and the open source JPOX project will host the reference implementation. JDO vendors (and there are many) are already offering many JDO 2 features in their products. In the Torpedo benchmark for ORM solutions created by TheServerSide.com, the top 2 performers are JDO implementations, beating out TOPLink, Weblogic CMP, and Hibernate.
– CMP/EJB – bleech. Too heavy. Only reason I’d use it would be to enhance my resume or get a job. Long learning curve. Complex development (XDoclet and IDE tools help). Performance may be an issue.
– JDO – Too limited. Not respected by many. Probably won’t last as a standard. Easier than EJB. Unsure about performance; should be reasonable.
– Hibernate – Best choice for O/R mapping. Best choice in general, really. Not hard to learn. Reasonable performance.
– Prevayler (not listed) – Best if you are making a very small system (in terms of data size) that WILL NOT grow significantly and you dont’ need a RDBMS. Very easy to learn. Pure OO. Fast development. Excellent performance.
– JDBC – Best if you need a RDBMS and are making a minimal system or a prototype. Difficult to apply good OOD. No learning curve (everyone knows it [or should]). Good performance.
Hibernate3 implements/will implement JSR-220 (EJB3) persistence, a major specification in the Java space with support from the big Java vendors. You can download preview releases (and Hibernate3 beta) from the JBoss/Hibernate websites.
No specification behind hibernate is a definite minus.
Developer familiarity with JDBC is a Plus +1 for JDBC. Most Java developers learn JDBC right after they learn Java. So most are pretty good at JDBC.
I’ve found CMP trivial to implement but BMP has much more efficiency than BMP… I’d almost rather see BMP listed here than CMP, but then again, most developers probably will disdain the thought of BMP.
-major vendors such as BEA and IBM voted against the JD0 2.0 specification
-Sun is promoting EJB 3.0 heavily and issued an open letter than mentions putting JDO into ‘maintenance’