Tim

You mentioned that external functions are loaded for each EDBSession and it started me thinking (always dangerous) that I might need to set up a thread pool rather than just creating them on the fly.

DBISAM sessions and databases were very fast to create but I don't know how much linking in some external functions might slow ElevateDB ones down. Can you let me know what other events might happen during the creation process for sessions and databases so I can take some wild guesstimates and think about session pools, database pools etc if it seems as though they might be needed.

I know its going to be very much a "how long is a piece of string" type operation but I'd like to prepare myself.

Roy Lambert

Roy,

<< DBISAM sessions and databases were very fast to create but I don't know
how much linking in some external functions might slow ElevateDB ones down.
Can you let me know what other events might happen during the creation
process for sessions and databases so I can take some wild guesstimates and
think about session pools, database pools etc if it seems as though they
might be needed. >>

The actual connection times, etc. for ElevateDB sessions and databases are
as-fast, or faster than with DBISAM.  However, please be aware that
populating the metadata from the catalogs/configuration file for
catalog/configuration queries can be slightly time-consuming if you are
querying many different catalog/configuration tables, so that is the main
thing to keep in mind in terms of what needs to be re-populated for each new
session and/or database.  The worst-case scenario is what the ElevateDB
Manager does, which is load every single piece of metadata when connecting a
session or database.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>The actual connection times, etc. for ElevateDB sessions and databases are
>as-fast, or faster than with DBISAM. However, please be aware that
>populating the metadata from the catalogs/configuration file for
>catalog/configuration queries can be slightly time-consuming if you are
>querying many different catalog/configuration tables, so that is the main
>thing to keep in mind in terms of what needs to be re-populated for each new
>session and/or database. The worst-case scenario is what the ElevateDB
>Manager does, which is load every single piece of metadata when connecting a
>session or database.

I'm not too clear with what you're suggesting here. Is it along the lines of the more tables you have in a database, and the more databases to a session the slower it is?

Roy Lambert

Roy,

<< I'm not too clear with what you're suggesting here. Is it along the lines
of the more tables you have in a database, and the more databases to a
session the slower it is? >>

Yes, with respect to loading *all* of the metadata for each database.   IOW,
if you don't query the metadata at all after session connects like the EDB
Manager does, then you won't incur any overhead at all.  The overhead that
I'm referring to is strictly related to querying the system metadata via the
Configuration database and Information schema for the current database.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim
That's what I thought

Roy Lambert