Synopsis of 4.7.0int5 bug:

 A problem with db connection conserving code was introduced where
 instead of conserving connections, the existing connection
 to the database is placed in the background while a new  active
 connection is placed over it in the foreground.  The now effectively
'zombie' connections are held until the program exits.
 

 History of the problem:

4.7.0int3
TRGSim++ usage on the CAF triggers too many connections to
the database alerts. Investigation shows that all of these connections use connect string
cdf_reader/reader@cdfofprd.
 

Analyis of the problem:

Database connections are held by a DBManager::ConControl class,
singleton which holds containers of database connection holders. Database
connection holders are subclasses of DBManager::DBConnection, in the case of Oracle
databases the database connection holder class is DBObject::OTLCon.
Class OTLCon makes an actual database connection to the server.

The problem arises in the way the ConControl class assumes that database
connections will be used. Connections are stored in ConControl by two
maps or hash tables.  The first, called an IOMap is
connection_name->user/password@database, the second, called ConMap,  is connection_name->pointer_to_DBConnection class described above.
The API is designed to use a static method to the singleton
ConControl::instance()->getConnection(database_name) and return a
pointer to a DBConnection which has the oracle or mysql database
connection embedded in it.
This design means that  if database name 'db1' points to connect
string cdf_reader/reader@cdfonprd and database name 'db2' has the
same connect string, ConControl::getConnnection(db1) followed by
ConControl::getConnection(db2) will result in 2 database connections.

TRGSim++ was holding up to 6 connections at one time
 

4.7.0int4
A change is made to DBObjects package:

OTLCon is modified so that when its getConnection method is called by
ConControl::instance()->getConnection(), it iterates through the
two containters IOMap and ConMap looking for other connections that use
the same connect string.  If one is found, the pointer to the OTLCon in
the ConMap is returned instead of instantiating a new OTLCon as was done
previously.  This means that database connections are conserved, which
was verified by Simona and others running TRGSim++.
 

4.7.0int5
A problem is noted:
Core dumps on exit are traced to double deletes in the ConControl
object.  The ConControl destructor iterates through its ConMap,
destructing all its contents.  Unfortunately for int4, ConMap can
now contain two pointers to the same OTLCon, which does not like
being destructed twice.

The solution that is chosen is to modify OTLCon::getConnection
so it always returns a pointer to a new OTLCon, but as the OTLCon's
are actually connection holders they are constructed with the existing
oracle database connection if one exists that can be shared.  Here
is where the problem arose: a login() call to the low level oracle
libraries was being made at this step, effectively placing the existing
connection in the background as far as the server was concerned, but
having no effect on the connection as far as the client could see.
 

This change fixed the core dump on exit problem, and looking at things
from the client perspective conserved database connections.  The real
mistake here was not checking the connections more carefully  from the
server side. The checking that was done was misinterpreted, an
aggressive disconnect/reconnect feature was tagged into int5 and then un-tagged
at the request of Liz Sexton, all the database connection testing was
oriented towards this, and the 'zombie' connections were not noticed
until the 100K farms test.
 

4.8.0pre1

the above problem is fixed by altering the OTL code to not
log in over an existing connection