How do I set fetch size in JPA? I would like the cursor to read 2000 rows at
once to speed up entity generation. Thanks for help!
--
View this message in context:
For giggles, try this...
- Set the FetchBatchSize to 2000
- Execute your query
- Once you get the result back, iterate over the entire list before you send
it out to your client.
On Mon, Sep 12, 2011 at 2:17 AM, M. Walter marc.wal...@sbb.ch wrote:
How do I set fetch size in JPA? I would like
There have been a few emails to this list about classpath issues when
enhancing on Glassfish. I don't think there's a definitive guide to getting
automatic enhancement working though, and the general consensus is to use
build time enhancement.
That said, if you can resolve the classpath problem
What version do you have in your persistence.xml file?
If the xml header indicates version 1.0 you'll get OpenJPA's old behavior
(and the error message you're seeing). If you have 2.0 in the xml header the
JoinColumn annotation should work.
-mike
On Sun, Sep 11, 2011 at 1:49 AM, koenr
Hi again,
Some database drivers might allow you to specify the default fetch size in
connection URL or data source definition. For example, Oracle docs say they
have a defaultRowPrefetch property for this. Of course, this is not specific
to OpenJPA / JPA.
Greetings,
Milosz
Hello,
It
Hi,
I compared JDBC and OpenJPA speed of fetching simple entities (consisting only
of a single ID attribute). The speed difference seems quite severe.
With JDBC, I can read 2 million entities in about 3 seconds when OS/DB caches
are warm.
With OpenJPA using slice (a single slice), it takes a
Michael -
I wouldn't expect to see that large of a difference of JPA vs JDBC. Can you
describe your scenario a little better? Are you issuing just a single JPQL
to select all of your Entities?
Thanks,
Rick
On Mon, Sep 12, 2011 at 1:36 PM, Michael Pflueger
michael.pflue...@sma.dewrote:
Hi,
I
I could submit a zip including the tests and a persistence.xml tomorrow, i
guess.
That would probably be the most expedient way to figure out what is going
on.
Does anyone on the openjpa dev team run such performance tests?
We don't have anything (that I'm aware of) that runs as part of our
Michael,
The lock contention seems to be at a different place than at JDBC layer.
Can you please set
openjpa.jdbc.SQLQueryCache=false and see if th elock contention is reduced?
-
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: