When we were benchmarking GeoServer we ran into an interesting
observation - it
looked for all the world like requests were being serialized. This is
not cool
- but at the time we blamed the web container and went on.
The more I think about it though the more I wonder if it is some
horrible
synchornized tag to do with access to DataStores. Do you know if we
are
serialized at the moment - or is this expected behaviour.
Just to make sure, by serialized you mean that if you made two requests,
then the second would not return until the first did, right? So if the
first was really big then the second would take a long time, right?
I just tested with my largest data set, which led me to figure out that
we _do_ need autocommit set to false, at least for the current jdbc
driver that we have. Andrea said that he didn't when he was testing,
and that we should upgrade our driver. I don't have time to do that
right now, but in the JDBCDataStore code you just need a line that says
if (resultSetType == ResultSet.TYPE_FORWARD_ONLY) {
conn.setAutoCommit(false);
}
Ok, actually I just this. If anyone is really against it, or it messes
things up, roll the change back. Or if a new jdbc driver is put into
the geotools repository that does actually not need that call (though
the driver will need the encoding stuff updated).
This makes it so we don't load all the data into memory, which may have
been the cause of the serialization?
Or was the testing done with shapefile? If so then it is data source
specific, because I'm right now able to do a GetFeatures with
MaxFeatures of 2000, and issue a bunch of GetFeature requests on the
same featureType while the other is still returning its data.
But yeah, the code for setting autocommit to false does need to get in
there, that may fix the problem you saw. (I just updated geotools,
geoserver jar will need updating, if someone could do that for me
that'd be great since my internet is slow and commiting a 1.7 meg jar
is a bitch for me).
thanks,
Chris
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/