[mapguide-internals] Release of MGOS 1.2.0

[Bruce Dechant]

Multiple threads should not be accessing the GDAL provider concurrently,
however, when one thread is finished another thread can start to use the
GDAL provider and hence the same cached FDO connection. This might be
the "multiple" threads you are seeing. Is it not safe for the server to
reuse an existing GDAL FDO connection via one thread at a time or is it
safer to always start with a brand new GDAL FDO connection?

Thanks,
Bruce

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: June 28, 2007 1:57 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

Yes, there are multiple multiple threads sharing same connection to
provider.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom
Fukushima
Sent: Thursday, June 28, 2007 9:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

I thought we had eliminated the multithreaded access to the FDO GDAL
provider; i.e., all access to the GDAL provider has been serialized.  If
the MapGuide server is still accessing the FDO GDAL provider
simultaneously with multiple threads, then there is a defect in the
server.  We should fix the server in this case.  Haris, have you seen
where the server is failing to serialize the access?

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Thursday, June 28, 2007 1:20 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Release of MGOS 1.2.0

Folks,

In discussions with Haris, it has become clear to me that the stability
problems relate to using fdogdal in multithreaded fashion with no
internal serialization.

The underlying GDAL library is "fairly" threadsafe as long as only
one thread at a time is accessing a given dataset.  But even that is
not at all assured under the current use pattern.

I think we need to put a BigLock (tm) around GDAL in fdogdal 3.2.2
and a finer grained locking system in fdogdal 3.3 (trunk).

We could use Haris' patch though from a quick description it does
not sound to me like it is comprehensive.  I'm also willing to prepare
a fix for this if someone can test it heavily.

I'd add that there is no (apparent) way of testing multithreaded
access in the current regression tests for FDO which is a bit
unfortunate.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals