Pitfalls and practical Use-Cases: Toplink, Hibernate, Eclipse Link, Ibatis ...

Question

I worked a lot with Hibernate as my JPA implementation. In most cases it works fine! But I have also seen a lot of pitfalls:

• Remoting with persisted Objects is difficult, because Hibernate replaces the Java collections with its own collection implementation. So the every client must have the Hibernate .jar libraries. You have to take care on LazyLoading exceptions etc. One way to get around this problem is the use of webservices.
• Dirty checking is done against the Database without any lock.
• "Delayed SQL", causes that the data access isn't ACID compliant. (Lost data...)
• Implict Updates >> So we don't know if an object is modified or not (commit causes updates).

Are there similar issues with Toplink, Eclipse Link and Ibatis? When should I use them? Have they a similar performance? Are there reasons to choose Eclipse Link/Toplink... over Hibernate?

Answer 1

Can't comment on other implementations but for DataNucleus AccessPlatform ...

1. Remoting can require "jdo.jar" to be present since the model classes are bytecode enhanced. Alternatively if used "read-only" on the remote side then use un-enhanced classes there and all works without the additional jar.
2. Dirty checking is done via bytecode enhancement so no need to go to the datastore to see if a field is dirty (and you can have control over locks when you want to go to the datastore). Obviously this gives significant performance advantages over reflection based implementations.
3. I know of no "lost updates" possible; use of optimistic locking helps.
4. You can get implicit updates due to "managed relations" (where you have a bidirectional relation and you only change one side, so DataNucleus updates the other side to be consistent ... at flush()). You can turn off "managed relations" (up to a point). You can easily enable versioning of objects and know if an object is modified or not.

Reasons to choose DataNucleus are documented here

HTH

--Andy DataNucleus

Answer 2

I can share my fair amount of Hibernate pitfalls:

• Criteria API is not typesafe
• Criteria API is relatively bad designed (ex: you cannot retrieve the current aliases)
• If you create an alias, you are forcing a inner join (this is in the docs but is misleading)
• No support for UNIONs
• No easy way to 'de-proxy' a persistent object (remoting is supported by third parties)
• No support for tables without PKs (I now it's dumb but it happens in legacy schemas)
• No easy way to use sequences for non-PK columns (not so dumb)

As for most JPA implementations, I always found that I'd have to rely on some custom annotations or so to do stuff that it is not covered in the JPA spec.

Answer 3

Are there reasons to choose Eclipse Link/Toplink... over Hibernate?

In O/R mapper developer land (where I live ;)) it's a common fact that Toplink is considered to be the most feature complete and best O/R mapper out there. It has its weaknesses, but its vast number of features makes it something that's hard to beat. As it's now open source and free, I'd give it a try.

iBatis is not really an O/R mapper, it is more of a class filler/persister through hard-coded SQL. So you've to do the heavy lifting and have to write all queries. iBatis is useful when you're using a database with stored procs and have to utilize these procs for DML/set retrieval.

Answer 4

In regards to Ebean ORM http://www.avaje.org and your Pitfalls:

Remoting

You can use "vanilla" mode on a query and then Ebean will return plain beans and collections. This only works when you use "dynamic proxies/dynamic subclasses" but not if you use Enhancement (as the entity bean classes are obviously enhanced).

Dirty checking is done against the Database without any lock.

I believe you mean Optimistic Concurrency Checking? If so then by definition it is done without an explicit DB lock. You need to use Pessimistic Locking instead if you want/need a DB lock (select for update etc) - so I don't follow your point there.

Delayed SQL

Ebean doesn't have sessions and so it doesn't have session flush(). The SQL can still be delayed with Ebean when you use JDBC batching but it is not the same delay that you get with session flush().

Implicit Updates

A common complaint we hear from ex-Hibernate and ex-JPA folks. Ebean is architected without a session/entityManager. Instead you need to explicitly save() a bean or have that cascade to related beans. So yes, no implicit updates with Ebean.