[fdo-internals] RE: FdoThreadCapability
douglas at cpqd.com.br
Wed Oct 10 12:16:58 EDT 2007
Actually I'm not using the WFS Provider, we developed our own provider. The
FDO API we are using is from the 3.2.x branch (all with MapGuide Open Source
1.2.0 as client).
I observed that all other providers (at least the ones on the 3.2.x branch)
are returning PerConnectionThreaded capability. Is this property really
It makes no sense for our provider to execute one request at a time because
the request hard processing is done in other machines... it could be
parallelized... the map is taking toooooooo much time to get refreshed....
> Which version of the WFS provider are you using? The 3.2.3 and 3.3
> versions of the provider are PerCommandThreaded.
> -----Original Message-----
> From: Douglas Gardim [mailto:Douglas at cpqd.com.br]
> Sent: Wednesday, October 10, 2007 8:06 AM
> To: fdo-internals at lists.osgeo.org
> Subject: FdoThreadCapability
> I'm testing an FDO Provider implementation that was supposed to be
> Multithraded (the provider is returning
> FdoThreadCapability_MultiThreaded in
> the FdoWfsConnectionCapabilities::GetThreadCapability() method). But I
> noticed that my Fdo Provider client (I'm using it with MapGuide) is not
> multithreading its SelectCommand requests. It just executes a new
> SelectCommand after the previous one was completely processed and the
> FeatureReader is closed.
> Does anyone know how can I change this behaviour?
> thanks in advance.....
> View this message in context:
> Sent from the fdo-internals mailing list archive at Nabble.com.
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
View this message in context: http://www.nabble.com/FdoThreadCapability-tf4600354s18162.html#a13139085
Sent from the fdo-internals mailing list archive at Nabble.com.
More information about the fdo-internals