[fdo-internals] RE: FdoThreadCapability

[Traian Stanev]

The reason the server has to pool connections is that they are
PerConnectionThreaded, not the other way around. If the connection is
PerCommandthreaded, there would be no need of pooling on the server
since the same connection object could be reused from multiple server
threads, allowing the single connection to cache data itself, rather
than having 10 connections open, each caching possibly the same data.


Traian


> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: Wednesday, October 10, 2007 2:21 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] RE: FdoThreadCapability
> 
> At this time I recommend using PerConnectionThreaded. This is the
> setting that MapGuide sever is utilized to employ most effectively.
The
> MapGuide Server will create and cache an number of connections
> (possibly
> to the same server) that will allow some performance improvement.
> 
> Greg
> 
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Douglas
> Sent: Wednesday, October 10, 2007 12:17 PM
> To: fdo-internals at lists.osgeo.org
> Subject: [fdo-internals] RE: FdoThreadCapability
> 
> 
> 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
> used?
> 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....
> :(
> 
> 
> 
> gregboone wrote:
> >
> > 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
> >
> >
> > Hi,
> > 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.....
> > Regards,
> > Douglas
> > --
> > View this message in context:
> >
> http://www.nabble.com/FdoThreadCapability-
> tf4600354s18162.html#a13134398
> > Sent from the fdo-internals mailing list archive at Nabble.com.
> >
> >
> > _______________________________________________
> > fdo-internals mailing list
> > fdo-internals at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/fdo-internals
> >
> >
> 
> --
> View this message in context:
> http://www.nabble.com/FdoThreadCapability-
> tf4600354s18162.html#a13139085
> Sent from the fdo-internals mailing list archive at Nabble.com.
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals