views:

556

answers:

2

I have a large application that uses EJB 2.x entity beans (BMP). This is well-known to be a horrible persistence strategy (I can elaborate if necessary).

I'd like to start migrating this application to use a much more expressive, transparent, and non-invasive persistence strategy, and given my company's previous experience with it, Hibernate 3.x is the obvious choice.

Migrating to Hibernate is going to take a while, as over 100 tables in the application use entity beans. So I'm looking at a phased approach where the two persistence strategies run in parallel, ideally on the same tables at the same time, if possible.

My question is, what are the pitfalls (if any) of combining these two persistence strategies? Will they get in each other's way?

+1  A: 

I guess the thing to really be careful with is working with the Hibernate sessions. Hibernate caches stuff, and that might get in the way.

Frankly I would recommend that if you adopt Hibernate, drop the Entity beans entirely. Do your Hibernate work within session beans and let the session beans manage your transactions.

Or alternately use EJB 3, which is Hibernate standardized into the Java Persistence API.

jodonnell
A: 

As said jodonnel, you have to pay attention to caching, because if you use second-level caching in Hibernate and a table is modified outside of Hibernate, then Hibernate has no way to know that its cache entry is stale.

For the transactions, they should both use JTA provided by the container, so for that it should be safe.

Damien B
The same applies to the first-level cache (the session)
Ken Liu
If you use long sessions yes. But it's not really advised to.
Damien B