Martin Kal�n wrote:
Postgres (for example) don't use cursors on default. The PG jdbc
driver loads the entire ResultSet all at once and keeps it in memory!
So, even if you do a getIteratorByQuery the memory load on a large
resultset is huge!
You can get around this, if you set the fetchsize on the jdbc statement
for example:
stmt = con.createStatement();
stmt.setFetchSize(1);
ResultSet rs = stmt.executeQuery(sql);
This actually forces the jdbc driver to use a cursor and browse the
resultset one by one.
There was no regression when running the test suite with fetch size=1
(and it actually ran a tiny bit faster, presumably because of less
JVM allocations for objects not used in the tests).
I will re-run again and check peak JVM heap usage before/after and
bring it up on the development list.
I ran PB and ODMG API tests with the old platform (setFetchSize unspecified)
vs. setFetchSize(1) as per your recommendation.
See:
http://people.apache.org/~mkalen/ojb/postgresql-fetchsize-tests.html
Since this is on an OJB global level for PostgreSQL I guess that "1" might
be too low to strike a balance between network traffic and memory consumption?
It might be possible to use fetch size 1 explicitly only for iterators,
I will have a look at this too.
For normal statements lower fetch size = higher network traffic and more
JDBC communication overhead and might not be a good default setting.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
