Rick
I consumed your changes as a patch to OpenJPA 2.3.0 and can confirm that
they resolved my performance issues.
Thanks for your help!
Cheers,
Jeff
On 2/19/2014, 4:39 PM, Rick Curtis curti...@gmail.com wrote:
Jeff -
I recommitted the changes for OPENJPA-2285 to trunk. Please give them
Jeff -
I recommitted the changes for OPENJPA-2285 to trunk. Please give them a try
and let me know how it goes.
Thanks,
Rick
On Mon, Feb 17, 2014 at 10:35 AM, Jeff Oh jeff...@elasticpath.com wrote:
Rick - that would be fantastic.
Thanks for your help!
Jeff
On 2/15/2014, 5:32 AM, Rick
Rick - that would be fantastic.
Thanks for your help!
Jeff
On 2/15/2014, 5:32 AM, Rick Curtis curti...@gmail.com wrote:
Jeff -
I'll recommit the changes in OPENJPA-2285 back to trunk on Monday. Will
those changes be sufficient for your scenarios?
Thanks,
Rick
Jeff Oh, Sr. Software
Jeff -
I'll recommit the changes in OPENJPA-2285 back to trunk on Monday. Will
those changes be sufficient for your scenarios?
Thanks,
Rick
On Fri, Feb 14, 2014 at 9:15 AM, Rick Curtis curti...@gmail.com wrote:
Jeff -
As I said earlier, if there¹s work to be done, I¹m happy to submit a
Jeff -
As I said earlier, if there¹s work to be done, I¹m happy to submit a
patch - but I¹d like some consensus around what the patch should do first...
I talked with a few teammates yesterday and I think we're on the same page
as you. I will do some digging to try to figure out why I backed
Another question we have is what exactly was the internal test
regression that caused the rollback?
The company I work for (IBM) does a huge amount of functional server based
testing internally. When changes are made, the OpenJPA unit tests are the
first line of tests and occasionally the UTs
As I eluded to in the JIRA, the root problem is that in the JPA 2.0 spec,
the concept of Cache/CacheStoreMode/CacheRetrieveMode/etc/etc was added
and
this change was not honoring that contract. The crux of the problem is
that
the default value for CacheStoreMode is USE and the spec says[1] that
Hello,
We’re currently migrating an application from OpenJPA 1.2.2 to OpenJPA 2.3.0,
and have found that DataCache efficacy in our application declines
significantly from 1.2.2 to 2.3.0, to the point where our overall system
performance has declined by about 25% with the version upgrade.
Hi, Paul,
Thank you for sharing your experience. You've given me some very good
hints. I'll continue to play around with this and maybe post more
questions later.
Cheers,
=David
On Sun, 2009-04-26 at 22:39 -0700, Paul Copeland wrote:
Hi David -
No I did not say that at all. Just that
Right.
So, you're saying that it's not possible to do one batch transaction
with the DB when there are joins involved?
Thanks,
=David
On Thu, 2009-04-23 at 21:06 -0700, Paul Copeland wrote:
It makes sense that it would do a query per primary key (all in a single
transaction). There is a
Hi David -
No I did not say that at all. Just that from the information presented
there is no reason necessarily to expect different performance from
what you reported.
The SQL could be returning large numbers of rows (we don't know). Say
you have 100 mesh2_term objects in the findall
It makes sense that it would do a query per primary key (all in a single
transaction). There is a join of variants with the main table for
each such query indicating I guess eager fetching in the join.
Depending on the number of variants this could be a large number of
rows. That as much as
Tried setting this:
jdbcFetchPlan.setFetchBatchSize( -1 )
.setMaxFetchDepth( -1 )
.setEagerFetchMode( FetchMode.PARALLEL );
and this:
property name=openjpa.jdbc.DBDictionary value=batchLimit=-1/
but no difference...
My data store is PostgreSQL. Driver is org.postgresql.jdbc3 v
Ok, now I see why!
findAll( Class, Collection )
actually executes one transaction for each PK in the collection!!
Here is an excerpt of the log.
8428 openjpa TRACE [$Proxy26:1240220275057:task1] openjpa.jdbc.SQL -
t 27011334, conn 15221176 executing prepstmnt 30712384 SELECT
t0.value,
Thank you, I'll give that a try.
On Fri, 2009-04-17 at 07:55 -0700, Paul Copeland wrote:
That sounds interesting. You might turn on verbose logging for SQL
operations (openjpa.jdbc.SQL) and see what queries are actually being
executed. The logging section of the OpenJPA manual explains
Hello,
I'm not at all an expert in databases, so I don't know if this is a JPA
thing or a DB thing.
In any case, I'm using Postgresql. Using the findAll( Class,
Collection ) method, I am doing a lookup by PK. Since there is an index
like so on the table:
table_pkey PRIMARY KEY, btree (id)
That sounds interesting. You might turn on verbose logging for SQL
operations (openjpa.jdbc.SQL) and see what queries are actually being
executed. The logging section of the OpenJPA manual explains this.
On 4/17/2009 3:41 AM, David Leangen wrote:
Hello,
I'm not at all an expert in
--- On Sun, 2/1/09, is_maximum mnr...@gmail.com wrote:
From: is_maximum mnr...@gmail.com
Subject: Re: [URGENT] performance issues
To: users@openjpa.apache.org
Date: Sunday, February 1, 2009, 10:33 PM
Hi Kevin,
Sorry for replying late, I was facing a rush of work.
Well we didn't change
classes used for testing.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2241065.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues
classes used for testing.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2241065.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Pinaki Poddar on 29/01/09 05:09, wrote:
2. Build-time enhancement i.e. to execute one command after compilation
performs best and minimizes complexity of load-time-weaving. I have never
understood what really makes people to avoid 'build-time enhancement' -
especially when most of the apps are
requests will fail
because their fetched entity is no longer valid. As I know using
optimistic locking is not a good option for the entities with very
frequent update actions.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2238071.html
Sent
classes used for testing.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2239148.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
/enhancer.xml
It shows one way to enhance 100's of Entity classes used for testing.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2241065.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--performance-issues-tp2232295p2232295.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--performance-issues-tp2232295p2232295.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2233824.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2232295.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2233824.html
Sent from
locking is
not a good option for the entities with very frequent update actions.
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2237146.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Hi,
OpenJPA 1.0.0
Oracle 10g R2
Is there any known performance issues with either self-reference or circular
reference? When I analyze Oracle SQL trace, it reports the CPU and number of
queries way too high for tables which have only 10 rows!
THE PERSISTENCE CLASSES:
public class Taxonomy
29 matches
Mail list logo
