Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top