[fdo-trac] #65: GDAL: Connection RefCount incremented for internal worker objects

[FDO]

#65: GDAL: Connection RefCount incremented for internal worker objects
------------------------------+---------------------------------------------
 Reporter:  gregboone         |         Owner:  gregboone
     Type:  defect            |        Status:  assigned 
 Priority:  major             |     Milestone:  3.2.2    
Component:  GDAL Provider     |       Version:  3.2.2    
 Severity:  1                 |    Resolution:           
 Keywords:  refcount, addref  |   External_id:           
------------------------------+---------------------------------------------
Comment (by 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.

-- 
Ticket URL: <http://trac.osgeo.org/fdo/ticket/65#comment:6>
FDO <http://fdo.osgeo.org/>
Feature Data Objects