I am willing to throw out some numbers. :-) I am currently in the process of replacing Hibernate with iBATIS in a web application.
The primary reason for this is performance. I do not disagree with you that Hibernate can be made to perform well. I do think however that it has been presented as a general purpose persistence tool, and that it is not. In my experience, Hibernate works best when two criteria are met: 1) You are creating a database for a specific purpose, from scratch 2) You are creating the ONLY application that will access that database If your application does not meet those two criteria (ours did not meet either), then Hibernate is not a good match. With caching on and other people touching the data it is volatile at best. Without caching, it is painfully slow. For example, on the application I am working on, we changed a screen that accessed a large amount of data. The time to draw that screen changed from over 10 minutes (we killed it after that, and are not sure how long it would have run unchecked) to under one. In the case of smaller sets of data, we went from several minutes to sub-second responses. Larry On Fri, 11 Mar 2005 15:12:09 -0700, Kelly Harward <[EMAIL PROTECTED]> wrote: > Not sure that there is a lot of value in throwing around any kind of > empirical numbers since they will certainly vary greatly depending on > numerous factors (the query you're executing, network latency, the actual > RDBMS underneath, the amount of data in the database, proper use of indexes, > etc.). However, in benchmark scenarios we have worked on, it's more common > than not with Hibernate to see response times on par with straight JDBC. The > thing one may be tempted to discount in these kind of comparison benchmarks > is that in a plain ol' JDBC scenario you still have to marshal the JDBC > ResultSet to your domain objects (typically POJOs) if you really want to > compare apples to apples. Remember, Hibernate gives you collections of Java > objects - not a JDBC ResultSet (which, in my view, is a huge win in more > complex J2EE architectures). Granted, there may very well be some of your > existing queries that will appear slower with a generic Hibernate > implementation. We picked a few of our nastiest ones and found that after > some tuning we can get performance from Hibernate that is on par with > straight JDBC. > > I'm not trying to make the case that Hibernate (or similar frameworks) will > always be the best persistence solution for every J2EE app. Rather, I think > it's a mistake to discourage their use as a rule on the grounds that these > frameworks are not performant. > > HTH, > -Kelly > > -----Original Message----- > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Sent: Friday, March 11, 2005 1:24 PM > To: 'Struts Users Mailing List'; [EMAIL PROTECTED] > Subject: BRANCH: Typical Struts development team and distribution of tasks? > > What are your response times? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
