These are two different caching scenarios we are talking about. Tomcat connection pooling caches "Connection" objects.. not your domain objects. However, Hibernate caches business objects (POJOs). You could use Tomcat's connection pool along with Hibernate's pooling of business objects.
I do believe using Hibernate has tremendous advantages over not using it ... specially in mid-to-high complex projects - specially from a maintenance and extendability point of view. Performance wise I dont think there is a huge difference... unless you use JDBC and write custom caching (very very specific to your needs as Hibernate provides decent level of caching). Hibernate has very good documentation too and is quite mature. So you should use it unless you have a strong reason not to ! :-) Regards, Raghu On 11/28/05, pc leung <[EMAIL PROTECTED]> wrote: > > Hello Larry, > If a webapp uses, say, tomcat connection pool and JDBC, does it equal > to what you call caching? > > > On 11/28/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > > I disagree Paul. :-) > > > > I believe that using a tool such as iBATIS can make an application use > > resources more efficiently by converting JDBC objects into POJOs, and > > caching database access. Even though the initial data request from the > > user may be slower (by a couple of ms), future requests for that same > > data will be MUCH faster, because of caching. > > > > While you could do that same caching with JDBC...that means you are > > turning JDBC objects into POJOs yourself, which takes longer to code, > > and does not benefit your application as much as you may think. I am > > not sure where your 2x-10x performance difference came from, but in my > > experience, I have not seen that. > > > > I think that greater performance gains could be realized by using > > iBATIS to provide data mapping and caching, and then optimizing the > > database performance using stored procedures. > > > > Larry > > > > > > On 11/27/05, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > If you have extremely high performance requirements, don't deal with > > > anything that does reflection - do straight SQL over JDBC. > > > > > > Paul > > > > --------------------------------------------------------------------- > > 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] > >
