Okay, I finished investigating making Queries w/o FIDs.
According to the profiler, I was expecting an approximately 15-25% speed
increase.
The actual results were not as expected (for reading and rendering
100,000 lines - average 83 points/line in the original data, very high
decimation during rendering):
My laptop (single processor, windows) about 5% faster.
Sigma (2 processor, linux) about 11% faster.
The dataset appears to fit in the disk cache - the first run takes about
3 minutes on my laptop (with the disk going crazy), and about 30 seconds
each request after that. On sigma the first run takes about 1 minute
(it has a raid array) and the rest about 15 seconds.
My bet is that there is IO (ie. socket xfer, round trips to the DB) that
is starting to be the limiting factor.
Changes
---------
There's no changes if you dont set the transaction property
"doNotGetFIDS", but if you do set it:
jdbc.QueryData constructor:
//DJB: allow for transaction-level FID mapping
if (transactionSaysDontGetFIDS(transaction))
{
this.mapper = featureTypeInfo.getFIDMapper(); //old way
}
else
{
this.mapper = new NullFIDMapper2(); //dont bother getting
anything for the FIDS
}
jdbc1datastore
constructQuery() has two changes (1) added a Transaction parameter (2)
it has code like the above to construct the appropriate FID Mapper.
Renderer
a) added doesntHaveFIDFilter(Query/Filter)
+ looks in the filter for a <FIDFilter> element
b) query now looks like this (FeatureSource doesnt allow you to set a
Transaction):
...
if ( (featureSource instanceof FeatureStore) &&
(doesntHaveFIDFilter(query) ) )
{
try{
FeatureStore fs = (FeatureStore) featureSource;
if (fs.getTransaction() == Transaction.AUTO_COMMIT)
{
// play it safe, only update the transaction info if
its an auto_commit
// it logically possible that someone could be
using the Transaction to do future (or past) processing.
// We dont want to affect a future Query
// thats not possible with an AUTO_COMMIT so its
safe.
Transaction t= new DefaultTransaction();
t.putProperty("doNotGetFIDS",Boolean.TRUE);
fs.setTransaction(t);
}
}
I'm not sure how this will affect the other JDBC datastore, but
theoretically there shouldnt be any problems - as long as their either
use both the above function (jdbc.QueryData/jdbc1datastore) or neither.
I'll commit this next week incase anyone wants to comment in the next
few days.
dave
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
