I am looking for some suggestions regarding usage of Hibernate for our product.
Our product deals with approx. 1.2 million records a day.
So, the data store will contain huge amount of data.

It's basically a product that processes transactions. (online and batch)

Performance is the key deciding factor in order to finalize technologies.

Also, we envisage usage of a different database by a different customer of our product.
We have the following choices:
- Use Hibernate to achieve database vendor transparency
- Use customization approach for each customer, customize SQL related code / queries based on the database server used by our customer.

I would like to know what would the effect on performance if we use Hibernate (with the amount of data our product has to handle) - when compared to using JDBC?

Can someone please provide some guidance?

Thanks in advance.
- Sriram

It depends on how much data each transaction deals with. If it is relatively small (like say, less than 100 objects), then a Hibernate solution will perform as well as, or better than straight JDBC.

If there is a large amount of data (tens of thousands of objects) dealt within each transaction, then available releases of Hibernate show some weaknesses. HB 3.1 adds stateless sessions to make this easier than it has historically been.

Thanks Nebob for your reply.

The objects will be less than 100, but the number of rows will be more.
for example, Transaction table will have millions of records - but the number of objects linked to transaction table will be 4 or 5.

My concern is related to huge amount of data that needs to be parsed.

So, what is your opinion for this kind of scenario?

We are using Hibernate 3.0 and we did not have any performance problems. Currently our system handles about 4 millions of requests per day (at the app server and the database level). They are all online primarily. Our main tables contain about 50 millions records and the transaction table - 1,4 billions (but actually the table is partitioned and not all data is accessed). The system performed quite well during the performance tests, which tried to simulate the production load and this weekend we are going live :). The only thing, which bothered us was objects creation rate and garbage collection frequency at the application server. Both statistics were quite high and we had to fight with the JVM heap settings.
Our main batch processes are done through the database. If you need good performance both for online and batch processing, you should consider different approaches for their implementation.