GDAL: Connection RefCount incremented for internal worker objects

[gregboone]

When the GDAL provider connection is created and Open() is called, the resulting RefCount should be 1. With the GDAL provider the RefCount is incremented to 3. These additional increments are caused during the Open process as the connection object is passed, via method parameters, to several internal worker objects (including FdoRfpClassData and FdoRfpGeoBandRaster) who in turn call AddRef on the connection. When dealing with internal worker objects, whose lifespan is guaranteed to be the lifespan to the connection, these types of object should only hold soft references to the connection object so that a circular dependency does not occur. The solution to this issue is to not AddRef the connection when storing the connection pointer as class data.

[gregboone]

In general, calling AddRef on an object in the constructor is not a bad thing. However, generally we do not do it for connection objects unless the containing object is to be directly passed back to the client for processing. Such an example would be a FdoICommand or FdoIReader object. These objects definitely have to have their connections refcounted otherwise they may become invalidated. However, for internal helper objects that contain constructed schema or other such information, we should not follow the same rule. These objects never live outside of the provider dll and their lifespan is always controlled by the calls to open and close. It makes no sense to Addref the connection once again in this case if the connection is parent and the only user. No other provider in our set of providers does this.

This problem in the GDAL provider was causing a subsequent error in MapGuide

In the following sequence of FDO calls the reference count of the FDO connection stays at 1, except GDAL, where it goes to 3.

pFdoConnection = m_connManager->CreateConnection(provider.c_str()); Reference Count = 1 after this pFdoConnection->Open(); Reference Count = 3 after this call for GDAL only, otherwise = 1

The above is a problem because MapGuide cannot use the reference count to determine if a connection is no longer in use, ie: RefCount = 1.

It is obvious that by calling simply calling Open(), the connection should not be deemed in use. It should be in a ready state awaiting the construction of various FDO commands.