Hi there,

we are in the situation of choosing one persistence framework for a J2EE project. The finalists are Hibernate and Apache's OJB, not necesarily in this order. Can you give me some hints about what Hibernate does better and (if possible) what does worse ;)

Thanks,

Florin

Look at the small example app in the eg directory of the Hibernate 2.1 download, and then try to reimplement it an any other ORM.

It has long been my policy to not comment on other competing products.

That was my first impression too. Hibernate is easier to work with. So from this point of view for sure Hibernate is the winner (even if it has no GUI :) ... who needs it anyway). Also considering the documentation, the one for Hibernate seems to me more intuitive and more complete, the one for OJB is unfinished.

But I was wondering if there are any "hidden" things such caches, transactions, locking or any other performance issues which work better on one of the 2 tools.

Unfortunatelly the time is short and we do not have time to test too much.

Thanks for your feedback,

Florin

Ok - now you are asking a concrete question, i'll answer ;)

Note: I used OJB before I jumped ship and started using Hibernate (and i'm still following what OJB is doing)

I'll just list the reasons why I shifted from OJB 2 Hibernate:

At the time, OJB (in their core API, called PB API) used a global static singleton cache for all sessions - that is NOT GOOD when you want to have multiple seperate threads running and you would like to have transaction isolation.

Lately they have made it possible to have more than one cache per session....BUT that does still not help you when you need more advanced stuff like true transaction isolation, locking et.al.

Their (OJB's) solution is to ask you to use their higher-level API's (such as ODMG) - but hey, this stuff (ODMG) requires special tables for managing object locks (note: NOT row locks) to ensure transaction isolation ....
And to get isolation I need to lock/upgrade/release my objects - but hey - I just want to use optimistic locking without any hassles....but that is (was?) not possible in OJB at the time (and it still is not supported in the basic PB API - at least not in a manner that it's thread safe)

I know OJB's arguments is that this stuff is provided by the higher level API's - but I don't buy that ;) ....in Hibernate the core API is designed for this stuff: concurrency, scalability and even simplicity ;)

So, yes - caches, transactions and locking surely is handled differently in OJB and Hibernate.....and I must say that Hibernate solves this issues in the core (where OJB chooses to solve it the higher levels and with a cost (extra tables and required lock/upgrade/relase statements ) ....and this will eventually have an impact on performance (depending on the scenario)

(and if someone from OJB reads this - then please correct me if I am wrong)

I am also a former OJB user who moved to Hibernate so here are some of my reasons

1)documentation - Hibernate's documentation is MILES beyond OJB
2)query language - HQL is far more powerfull than any of the query interfaces available in OJB, and much more intuitive
completeness - I have yet to find a feature missing in Hibernate when I needed it
3)Hibernate seemed to be able to work with our model more seamlessly - the only way to get the rich Object handling we wanted at the time from OJB was through the ODMG api, which required some persistence related changes to our objects.. with Hibernate we used truely POJO - the only persistence relevenat item in the objects were an OID field and timestamp field - easily handled as 2 fields on our base class.
4)Collection handling much more transparent

Archetecturally OBJ is very sound.. and the code is quite readable. I found this while chasing and stamping out a few bugs. From what I have seen of Hibernates code it is similar in cleanleness, but my exposer to Hibernates code is a bit lower, as I have had less need to fix bugs or add features ;-)

One thing that OJB seemed to be better at when we switched was more flexability in the way of plug-in pieces (persisters, etc) but Hibernate is quickly gaining, and may even be ahead in some places. It will be ahead for sure when Gavin completes a few more of the "pluggable interface" changes on his list

Hibernate activity level also seems much higher (subjective view, I havent counted mailinglist/forum messages or anything)