eXtremeDB connection pool

eXtremeDBworks in the same address space as the project that is using it. Thereis no cost for connects/re-connects. Strictly speaking, connecting to aneXtremeDB database costs the same as calling any other function. eXtremeDB doesnot allocate any additional memory, sync. primates, sockets and etc. for aconnection. For In-memory only databases eXtremeDB uses a pre-allocated recordfrom the connection array. For persistent databases it opens file handles forevery storage and log file. For shared-memory databases it maps a shared memoryregion to the local address space for the first connection (all other re-usethat mapping). All tasks (threads) runs in-memory (even file handleallocations). Real network-related processing, like TCP/IP dialogues, happenonly for HA/Cluster enabled databases or RSQL access and requires usingdifferent APIs (not just mco_db_connect()). So, there is no point inmaintaining any kind of connection pool.

 The connection is not a heavy resource, but still there is some overheadattached to creating/dropping connections, primarily associated with lockingthe database header while connections are created or removed. Also the numberof connections to the database is limited by the  maximum number ofconnections at the the the database is created. If the number of connectioncreated at runtime exceeds the maximum number specified through the db_paramsstructure, the application receives an error. Thus creating a pool of thedatabase connections is not a bad idea. However before adding the pool intoyour application in a spirit of not overcomplicating your code  I suggesttrying creating/dropping connections at the time of processing yourapplication's events.