[mapguide-internals] Raster provider problems...

[Bruce Dechant]

Limiting the pooling to 1 won't solve this as the server will simply use un unpooled connection on the 2nd GDAL request if the 1st is already in use.
 
Bruce

	-----Original Message----- 
	From: mapguide-internals-bounces at lists.osgeo.org on behalf of Robert Bray 
	Sent: Sat 4/7/2007 12:03 AM 
	To: MapGuide Internals Mail List 
	Cc: 
	Subject: Re: [mapguide-internals] Raster provider problems...
	
	

	Yea, guess you are right. For the vetted providers it could be marked
	per connection threaded, but we cannot blindly mark it that way.
	
	So that means there can never be more than one instance of the GDAL
	provider in use within the server. I wonder if we simply limit pooling
	on that provider to 1 if that would do the trick.
	
	Bruce what do you think?
	
	Bob
	
	Frank Warmerdam wrote:
	> Robert Bray wrote:
	>> Frank,
	>>
	>> Yes I am suggesting the server should take responsibility. At the same
	>> time I wonder if GDAL is not per connection thread safe. What that
	>> means is that the server will never use the same connection to GDAL on
	>> more than one thread at any give time.
	>>
	>> When you say GDALDataSet you mean the C++ object right?
	>
	> Yes
	>
	>  > Is a single
	>> instance of that ever shared between FDO Connection objects? If not
	>> then  the GDAL Provider can be marked as "Per Connection Threaded".
	>>
	>> The server as designed today will never assign an FDO Connection
	>> object to more than one thread at a time.
	>
	> Frank wrote:
	>>> I will note that GDAL is threadsafe under certain restricted
	>>> circumstances:
	>>>
	>>>  o Using only threadsafe vetted drivers (ie. GeoTIFF, HFA).
	>>>  o Only having a single thread touch any given GDALDataset at any
	>>>    one time.
	>
	> So, to reiterate, GDAL could be marked as per connection threaded if
	> we know that only vetted drivers were going to be used.  But GDAL has
	> many format drivers, most of which have not been meaningfully vetted
	> for multi-thread safety.
	>
	> Best regards,
	_______________________________________________
	mapguide-internals mailing list
	mapguide-internals at lists.osgeo.org
	http://lists.osgeo.org/mailman/listinfo/mapguide-internals