Mar 9th, 2009, 12:21 AM
Spring/Hibernate engagements in the wild?
Can anyone provide some examples of the classic Spring/Hibernate stack in large scale engagements? I'm looking for sites which have high performance and load requirements and the like.
(Basically, one of our architects has been trying to argue that Spring and Hibernate are a poor choice of architecture for a site with high-performance requirements. While said architect has claimed he has a "gut feeling", I'd rather provide some positive counterexamples to refute this claim)
Mar 9th, 2009, 09:55 AM
A gut feeling is certainly not enough. There are plenty of scalable high-load applications that use Hibernate and perform well. It would be silly to argue that. However, it is not just the load and performance requirements that should affect your decision. Object-relational mapping only works well when you can indeed effectively map your object model and your data model - without making one horrendously complex to fit the other. (I am actually repeating what I had already said in one other thread.) Many real-world systems - to work efficiently - require the object model and the data model to be designed separately - for each to best fit its purpose. A well-designed object model will tremendously facilitate the development on the application (e.g. Java) side, and a well-designed database schema will provide a very efficient and high-performance way to store and access data. The two models may or may not nicely map to each other afterwards. Applying ORM to systems where no reasonable mapping between objects and data tables can be done may result in a complete disaster. Personally, I am very skeptical about any code or schema generation - in complex real world systems. A very efficient object model, if mapped directly to data tables, may result in a terrible, unnecessarily complex and inefficient data model, as well as very complex and inefficient queries. On the other hand, a brilliant but not trivial database schema for a large complex application most certainly would result in an incoherent ridiculous object model if one attempts to generate such model from the schema. The point is: objects and data tables serve different purposes. Hibernate will significantly simplify development where objects can (or even should) be reasonably mapped to the data tables. Or, it can lead to some serious "artificial" complexity and inefficiency - when data access could be much more easily implemented, say, using Spring JDBC support. Use a technology if it indeed simplifies things and gets the job done, not because it is a flavor-of-the-day thing and "everybody is using it."
Originally Posted by dbrinker
Mar 9th, 2009, 11:04 AM
Typical 'architect'. In Dog we Trust. All others bring data.
Originally Posted by dbrinker
If he can't provide meaningful data to back up his 'gut feeling' then he's just showing a technology bias.
BTW, we are using Spring/Hibernate in a multi-faceted application that has a core of MessageDrivenPojo's that process tens of thousands of messages per hour, executing command chains that send jms messages, make multiple updates to the database and invoke webservices. While there are many things you need to do to tune high volume hibernate apps, especially WRT lazy loading of associations, there is nothing inherently performance limiting with spring/hibernate vis a vis handrolling your own persistence/ORM solution.
Last edited by chudak; Mar 9th, 2009 at 11:11 AM.