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]
