I am basically new to Hibernate. I am considering using this product on a mjaor product within my office. Before I make this descion, I have a few questions I'm hoping that someone may be able to help me with.

1.) My product environment is Distributed. What that means is that I have multiple servers talking to the same Database performing similar functions on the data at the same time. Is Hibernate capable of operating effectively in this environment? What options within Hibernate will I not be able to use because I am living in a Distributed Environment?

2.) I've run some tests with Hibernate vs. standard DAO. The performance is basically a wash with the DAO's out performing Hibernate at lower transaction threshholds and Hibernate winning at the higher transaction rate. The one thing I did notice is that the DAO's always perform with the same memory footprint, whereas Hibernate is constantly growing as I pass more data through it. It should be noted that the memory foor print is consisted when I run the same test over and over, but always larger when I run more data through it. Is there a reason why Hibernate does not seem to want to let go of memory (cacheing is turned off)?

3.) What is the likely hood of Hibernate going commercial and leaving its commercial users basically screwed like MySQL did?

1) Basically the same as with a JDBC application: You have to make sure that cached data in your Hibernate app gets evicted as soon as the database is changed. Use minimal caching and make sure you understand how transaction isolation levels work. But in principal there is no additional problem created by an OR-Mapper in comparison to a pure JDBC solution.

2) Have a look at http://blog.hibernate.org/cgi-bin/blosx ... batch.html this should explain some of the things you are experiencing.

3) None - Hibernate is LGPL licensed, and relicensing it under a diferent licens would require the agreement of every contributor (as we don't hand over our copyright to JBoss). This is basically impossible - Have a look at http://www.hibernate.org/263.html#A7 too

1) None, Hibernate is cluster-agnostic and does not implement any VM or cluster-scoped control mechanisms. It's designed for highly concurrent usage in any environment. Of course you can plug-in a clustered second-level cache provider (two are distributed with Hibernate).

2) Impossible to debug without tests, but I assume incorrect usage of the Session.

3) http://www.hibernate.org/Documentation/ ... luationFAQ

Thanks Michael and Christian for your answers.

The solution Michael gave for number two corrects the problem. My developer is also new to Hibernate and was trying prove a point.

Understand on #3.

#1. Christian, I'm not sure you even know what I am talking about. There is know clustering in this solution.

Michael, let me lay out a scenario:

1.) Server A queries the database.
2.) Server B updates the database.
3.) Server A queries the database again.

Will Server A know that Server B updated the data?

Would I have to always flush and clear my cache whenever I get or put data from/to the database? In essence, I can't use the memory persistence model available within Hibernate.

Just so you guys know, in a basic configuration of this system, I'm looking at a minimum of four seperate servers talking to the database at the same time.

One of my customers, once fully deployed will have 16 servers.

As long as your transaction isolation is correct, and you are careful with second-level caching, you won't have any problems. I really don't have time to elaborate on this, please read up on how the hibernate dual-layer-caching systems works, what your options are for cache control and how this relates with transaction isolation.

All I can say stuff like this can be handled (both with Hibernate and a JDBC system), but it is not an easy problem. You will have to do some resarch.

Hey guys,

Thanks for answering my bosses questions. I've been tasked as the one to evaluate and prove hibernate being a better solution than writing custom DAOs that access the DB directly...

I know all of this can be found in Chapter 15 of the user documentation (rtfm...heh) , but I wanted to clear up these points, or at least get a confirmation going...

1) "Distributed" transactions. For the sake of simplicity I will say that we will turn of second -level caching. Won't optimistic locking handle any problems we may have with versioning? All of our tables already have versioning fields, so my understanding of this is that we simply "use it" and hibernate will provide the appropriate exceptions when concurrent updates access the same data. (Even the merge option can sort of help with this I suppose.) That's all we want. I know it's right there in the docs. I was told that we might have problems with stale views, but I can't really find a problem where this occurs...I don't think we're going to have any processing of state across multiple requests, but even if we did aren't I able to just "re-connect" the data to the DB and request a new read? It seems simple enough to understand for me. I dunno...(PS I also don't see how DAO's solve this problem....How do they do that again? Oh they don't...That's right.)....

2) I don't know why this memory thing keeps coming up. I just wanted to repost a response so other users don't do a search and think you have a bug. Memory did not incrementally climb over time, it climbs while in the process of a transaction (duh...how can we do that without creating objects), but it always came back down to the same exact JVM memory footprint after each transaction. (I had second level cache turned off..) So...It's not always larger...It does take up more memory on a per transaction basis, but we are talking 33% more here...ANd of course when you add in the 55% faster portion of the equation I dunno...

3) I wanted to note that I have not had the same results in my tests on low level transactions...That is, hibernate beat DAO's hands down on every test comparison I've done so fare, maybe there are other tests I haven't seen?

The point is that this is a huge debate amongst the team members. I think your product is fuc$%%$ beautiful and elegantly designed. I've written hundreds of DAO's in my past and find it painful and annoying to have to maintain them and all the interelationships and cascading changes that occur over a large system, Hibnerate seems to solve this problem very well, on top of generating SQL and lazy loading statements that I'm sure 90% of DAO's implementations just can't provide. GRRRRRRRRRRRRRRRR!!!!!!

If you already have versioning in your tables, this helps a lot. You can just declare a version property in your mappings and hibernate will protect you from the "last update wins problem" - you will get a StaleObjectException. For other conflicts, transaction isolation is what counts - as long as you are in a transaction, the right isolation level will prevent others from "updating your working data behind your back".

So versioning is mostly relevant for "application transactions", where your data leaves the scope of a transaction.

We can discuss some of this on IM or something if you want, pass me an email.

Also, I can only recommend getting a copy of Hibernate in Action if you get into a serious evaluation, especially such architectural questions are well explained there, and many points are relevant for all ORMs, not only Hibernate.

Besides, there is nothing in Hibernate that prevents you from falling back to JDBC if needed - if you have a use case that is inefficient with Hibernate, just do a session.connection() and perform a plain old JDBC operation.

You are under the impression that sir Kuhnert actually devlops use cases. This is an important concept in any object oriented environment. As of yet, his woeful and pathetic attempts to do this simple task have failed.

I believe that Hibernate can be implemented within our application. I have doubts as to whether the developers that work for me are trully up to the task. They do have deadlines, and learning something new does add an element of risk.

Looks like flame bait to me....

I thought I should add, I just replaced your DAO's in about 15 minutes ;)

And I suggest you remember who you are talking to. You are on very dangerous ground with me right now.

Guys, take this to your company's forum or whatever you have. This is the wrong place.

I apologize to this forum for my remarks.

Only for the sake of history, because somehow this has become a very funny story around the office...It should be noted that dave was asked to leave shortly after his hand written DAO vs hibernate war had ended.

The climax I believe came in the boardroom where he ended up screaming at the top of his lungs "are you a DBA??? are you a DBA??? "...I only answered as meekly as possible "No, but if everything you're saying ~should~ be true, why is it that my tests cases always show hibernate performing faster?...."

Sorry dave...but you were a real fu$#$%-er . :)