Larry,

His question wasn't what is more efficient design wise. His question related to 
performance issues
only. IBATIS and Hibernate are very good, but straight JDBC will always be 
faster. That's the
truth. Besides that, he then has to weigh the fact that doing straight JDBC is 
pretty much
featureless and he loses many programatic help that ORM tools provide -- but 
that's not my call
:-) I was answering his question on performance only.

--- 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]
> 
> 



                
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to