At 08:40 AM 4/04/2006, you wrote:

>I just started using the IBO Admin components to handle backing up a bunch of
>FB DBs. (Before I'd been calling gbak from code and waiting on the process
>handle.) The resulting backups work fine, but I'm seeing memory leaks - one
>for each thread that backs up a DB.
>
>FastMM to the rescue, I found the leaks are due to some TIB_Session objects
>not being freed.

The IBOAdmin components invoke service manager operations, which use
a different API than data access operations. The IBOAdmin components
make their own connection to the database through the service
manager, which invokes the appropriate utility program from its
internal code. It's the utility program that makes the connection to
the database, based on the database handle that is acquired *for that
set of operations*.

Keep in mind that connections across the Local transport are not
thread-safe. Given that you are complaining about session leaks,
rather than AVs, I conclude that your data access app at least is
remote, or is using localhost.

So, more information about how your app is making its connections
would have been useful in troubleshooting this.

> Looking at the IBO Admin files, it's always using the
> default session, and I don't see a way (short of modifying the

code) to get it

> to accept another one. I know with IB you need to have a separate

session per

> thread, and that works great in a couple other apps I've written.

In the iboCore palette, you will find TIB_Session. Drop one into your
service module; name it UtilitySession or something else
useful. Then drop a TIB_Connection into the module (naming it
suitably, e.g. cnUtility) and set its IB_Session property to
UtilitySession. Make sure that you provide the Server and Path
properties, plus the means to pass the Sysdba or Owner username and password.

> So any ideas on how to prevent these leaks?

Render unto Caesar that which is Caesar's....separate server
operations from data access operations by creating your service
modules (datamodule or form or both) at run-time. If you want to
provide a user interface, that's fine, use a form and put everything
on it. But make it a modular form, or a "create once" form and
always make sure you destroy the module. Remove the
Application.Create statement for your module[s] from the DPR and
instead publish a variable for it in your main form (or wherever the
button or menu-click is that you want to launch it from).

>My first thought was wrapping the
>backup function in a critical section and calling the whole via Synchronize,
>but 1) that's pretty roundabout and defeats the point of running it in a
>thread with the rest of the DB creation code, 2) it'll hang the GUI thread
>while it's processing, and 3) would (I think) still leave one leaked
>TIB_Session.

This won't work, because you must not try to thread across a
connection. Your leaked sessions are happening because the IBOAdmin
component is creating its own connection to the database and the
connection object is creating its own default session. If you try to
force the existing connection to be threaded, it will cause AVs.

Make it your Golden Rule to purposefully ensure that everything is
clean and tidy by using explicit session objects for each
circumstance where a connection to the same database path is
required. So use an explicit session object for the main form as
well; and another explicit object for threaded data access
operations, e.g. isapi instances; and another that is used for
service manager calls. Always take care to clean up.

Helen