I have a legacy system using plain JDBC when communicating with the database. I am now thinking about introducing Hibernate in this application. However, I cannot rewrite the whole application at once, due to money and time constraints. Instead, I want to rewrite little bits here and there, over time, and finally arrive at a completely rewritten application.

Is this a good idea? Can Hibernate co-exist with my old JDBC connection pooling and JDBC connections, i.e., is it a good idea/possible to use Hibernate to persist and read data in some parts of the application and use plain JDBC in other parts? Or will this be an unholy marriage that cannot possibly succeed? :)

For example, what about caching? If Hibernate caches some data and the JDBC part of the application changes the data in this table, then the Hibernate part will read dirty data from the cache, won't it? Can you turn this cache off?

Kristoffer

Hi!

I am currently in the process step-by-step transferring a JDBC application to Hibernate. I have found, that Hibernate and JDBC can exist well.
If you can keep Hibernate-driven transactions and JDBC-driven transactions separate, you will have absolutely no problem. If you mix Hibernate-access and JDBC operations in one transactions, you have to take care. For example, Hibernate defers updates to the persisted data objects until the transaction is committed. If you want to perform JDBC operations based on such data you have to flush() the session.

There may be other issues but in principle it is possible -- and in my opinon not overly hard to do.

If you have some further questions, don't hesitate.

All the best,

René

Hi

You can very well do it. But be causious!!!!

You will have to use session and connection separately.
Keep in mind that SQL query will insert null in the database, which is a problem for Hibernate, which hibernate will not do it.

You will have convert one by one DB table with Hibernate.

we did it for a application with 200+ tables.

Bottom Line: It is Possible.

Thank you for the quick replies. It doesn't sound too hard. Great. :)

Edit: But can I use the same database table for both JDBC and Hibernate operations, or "must" I only use Hibernate on a table once it has been "Hibernated"? Different parts of the application access and write to the same tables, and I can't use Hibernate from all of these parts.

Kristoffer

Hi,

Its better to go table by table. Hibernate can co-exist with JDBC in a Single database.

Change all your DAO one by one.

As said, when the access happens between transactions, there will be no problem.

However I would second what one of the other participants in this thread wrote: In my experience, the best gain during migration is, if you convert one data-table at a time in all parts of the applications. Try it! You will see, that Hibernate is much more efficient in access time, generated SQL as well as in maintainability. It will be most impressive, when you start mapping your object relations from seperate SQL-join statements to Hibernate-mappings.

All the best,

René

Now it's time for us to decide whether to use Hibernate or not. However, the question from before still looms over us. There are some tables that are used by other applications (or sub-applications) and we cannot implement Hibernate in those, that is unfortunately out of the question due to a number of reasons. We do want to use Hibernate in the new application, but it *will* use some of the tables that the other applications use.

Will the caching in Hibernate, or something else, cause dirty reads or the like if we use this strategy? Let's take an example:

Suppose that the "William" record in the Person table is read by Hibernate. One minute late, this record is changed by plain JDBC-SQL from a sub-application to an "Ann" record, i.e., the column "Name" is changed. Another minute passes and now Hibernate wants to read this record again. Since it exists in the cache, it is read from there and now this application still thinks it is a "William" record and displays incorrect data for the user when in fact it is an "Ann" record.

Can this scenario occur? Can I prevent this scenario in any way? Do I need to switch off, i.e., not use, the query cache? Would that solve it?

Could I run into other problems with the strategy outlined above?

Kristoffer

You have two levels of caching in Hibernate. The first-level cache has the scope of a database transaction. On the bottom line: Until you plan to use second-level caching (which is obviously not an option in your scenario), you will face no issues other than those common to concurring database transactions and concurrent updates.

All the best,

René

Okay, thanks for clarifying that to me. Then I guess we'll use Hibernate. :)

Kristoffer