openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <techhu...@gmail.com>
Subject Re: Improving out of the box performance
Date Thu, 05 Feb 2009 16:25:41 GMT
Rick,

I think stressing the use of DBCP (with examples) in the documentation is a
great idea, but I don't think the dbcp library should be included in the
OpenJPA image since it isn't a required runtime dependency.  Most
application servers and some JDBC drivers provide their own connection
pooling so the dbcp library would be a extra baggage - albeit, carry-on size
:-) - for folks using OpenJPA in those environments/configurations.

-Jeremy

On Wed, Feb 4, 2009 at 2:20 PM, Rick Curtis <curtisr7@gmail.com> wrote:

>
> After reading this
>
> http://terrazadearavaca.blogspot.com/2008/12/jpa-implementations-comparison.html
> blog post , I decided to do some performance(ish) testing on my local
> system
> and I also came the conclusion that openJPA isn't the fastest out of the
> box(I don't think that's a surprise to anyone). It was easy to get
> something
> working, but it didn't work as fast as it could/should have. Ease of use is
> a high priority when a developer is trying out a new technology, but not
> the
> only priority.
>
> A steaming pile that is easy to use, is still a steaming pile. :-)
>
> In an attempt to make openJPA perform better out of the box, I'd like to
> see
> DBCP packaged with openJPA and have the docs updated to stress the use DBCP
> rather than a direct DB connection. This won't add much in the way of
> complexity, but it will help the performance greatly. I wrote a blog post
> about this very topic that can be found
>
> http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.html
> here .
>
> Any thoughts?
> --
> View this message in context:
> http://n2.nabble.com/Improving-out-of-the-box-performance-tp2271261p2271261.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message