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" wrote:
>Jeff -
>
>I recommitted the changes for OPENJPA-2285 to trunk. Please give t
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 wrote:
> Rick - that would be fantastic.
>
> Thanks for your help!
>
>
> Jeff
>
> On 2/15/2014, 5:32 AM, "Rick Curtis" wrote:
Rick - that would be fantastic.
Thanks for your help!
Jeff
On 2/15/2014, 5:32 AM, "Rick Curtis" 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 Engineer
Phone:
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 wrote:
> Jeff -
>
> > As I said earlier, if there¹s work to be done, I¹m happy to submit a
> patch - but I¹d
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 thi
>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] th
> 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 m
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.
We’ve
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
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
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
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
Tried setting this:
jdbcFetchPlan.setFetchBatchSize( -1 )
.setMaxFetchDepth( -1 )
.setEagerFetchMode( FetchMode.PARALLEL );
and this:
but no difference...
My data store is PostgreSQL. Driver is org.postgresql.jdbc3 v 8.3.603.
Cheers,
=David
On Mon, 2009-04-20 at 18:43 +0900, Dav
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 -
executing prepstmnt 30712384 SELECT
t0.value, t1.TERMVO_ID, t1.element FR
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
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 databases,
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)
send us the
> > log file?
> >
> > > value="File=c:\\trace.log,DefaultLevel=TRACE"/>
> >
> > Regards,
> > Fay
> >
> >
> >
> >
> >
> > --- On Sun, 2/1/09, is_maximum wrote:
> >
> >> From: is_maximum
> >> Subje
>
>
>
>
>
> --- On Sun, 2/1/09, is_maximum wrote:
>
>> From: is_maximum
>> 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
Hi,
Sometimes the OptimisticLockException is thrown because of the SQLException
during insert. Could you turn on the trace and send us the log file?
Regards,
Fay
--- On Sun, 2/1/09, is_maximum wrote:
> From: is_maximum
> Subject: Re: [URGENT] performance issues
>
ce. Enhancer
>> > fails mostly with classpath issues and availability of
>> > META-INF/persistence.xml etc.
>> >
>> > If you have access to OpenJPA source code, follow the trail at
>> > ./openjpa-persistence-jdbc/pom.xml and
>> >
./openjpa-persistence-jdbc/pom.xml and
> > ./openjpa-persistence-jdbc/src/main/ant/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.
>
>
il at
> ./openjpa-persistence-jdbc/pom.xml and
> ./openjpa-persistence-jdbc/src/main/ant/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.
hance 100's of Entity 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.
ocking how to
>> handle it? if a request changes an entity say Account, and at the same
>> time there are say 10 requests that are modifying the same account, the
>> first request will commit its changes and all other 10 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 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
all other 10 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-tp2232295p2237146.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
gt; >> We have a big problem in performance. We are using JProbe to inspect
>> what
>> >> happens in our code and there is a critical business method which is
>> >> required to have a high TPS but unfortunately this method is doing its
>> >> job
>> >> really slow.
>> >>
&
cer
> >> such
> >> as pcReplaceField(int), pcNewInstance() and generally pc* methods have
> >> long
> >> duration in compare to our methods.
> >>
> >> As I read in OpenJPA manual the enhancer is engaged to obtain higher
> >> performnce but in action we see a different re
t make enhancer not work properly or is there
>> anything else we should consider?
>>
>> I also enabled the data caching but strangely the performance has been
>> decreased!!!
>>
>> Please share your exprience with me.
>>
>> OpenJPA 1.2.0
>> Sun Jav
>
>
>
>
> value="ForeignKeyDeleteAction=restrict,JoinForeignKeyDeleteAction=restrict"/>
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2232295.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
r 9.1
-
persistence.xml
-->
--
View this message in context:
http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2232295.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 Taxon
33 matches
Mail list logo
