Opened 17 years ago

Closed 17 years ago

#65 closed defect (fixed)

GDAL: Connection RefCount incremented for internal worker objects

Reported by: gregboone Owned by: gregboone
Priority: major Milestone: 3.2.2
Component: GDAL Provider Version: 3.2.2
Severity: 1 Keywords: refcount, addref
Cc: warmerdam External ID:

Description (last modified by 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.

Change History (7)

comment:1 by gregboone, 17 years ago

Status: newassigned

comment:2 by gregboone, 17 years ago

Description: modified (diff)

comment:3 by gregboone, 17 years ago

Description: modified (diff)

comment:4 by gregboone, 17 years ago

Summary: GDAL: Connection RefCount incremented for Internal woker objectsGDAL: Connection RefCount incremented for internal worker objects

comment:5 by gregboone, 17 years ago

Description: modified (diff)

comment:6 by gregboone, 17 years ago

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.

comment:7 by gregboone, 17 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.