SessionAttach Resource Leak?

[DaveH]

Until very recently, we woulad have had no way to discover this potential problem, since our main app (using DOA quite successfully) only loads one TOracleSession, and logs in only once.

Now we are attempting to implement some plugins (packages, DLLs). Each of these requires access to the Oracle Database. If a TOracleSession is placed on each form, the form "leaks" resources like gangbusters when closed.

We have been unable to get SleuthQA to debug into the DOA Source, but each resource leak occurs at: DOA.bpl::ServerAttach

Not sure we had the right answer, we revised a couple of these plugins to use BDE/Tquery rather than DOA/TOracleDataSet, and voila, the resource leak went away.

That points us toward something in DOA causing the leak. We are still logging onto the same database and using the same Net 8 client, so they can't be at fault.

I'd be happy to further debug this if you can tell me how to get SleuthQA (Turbopower) to debug into the DOA components. Failing that, I'd hope that you might have a look.

DOA 3.3.3, D5, Oracle 8.0.5 and 8.1.6

Thanks.
DaveH

 

[Marco Kalter]

I created a little test program with a loop that creates, connects and frees a TOracleSession instance. The system monitor does not show any leaks, and Memory Sleuth does not detect any leaks either. I'm using Direct Oracle Access 3.4.3 and Net8 8.1.5.0.0. If you can create a similar program with a resource leak, send it to me and I'll take a look.

------------------
Marco Kalter
Allround Automations

 

[DaveH]

Of course, a test program. Almost impossible, since we're using a huge Oracle database, and a 40Mb of source. If I can, I certainly will.

In the meantime, I had not thought of the specific client in use. The development machine uses 8.0.4. Do you think that might make a difference? Perhaps there were issues with the 804 client that I'm not aware of?

Dave

 

[Marco Kalter]

It might be a 8.0.4 issue, I don't know. 8.0.4 was not really the most robust Net8 version Oracle has produced.

If you can create a little test program that creates a session, connects to the database, and frees the session in a loop, we can determine if there is a problem connecting and disconnecting in your environment. I certainly didn't want you to send me your entire database and application.

------------------
Marco Kalter
Allround Automations

 

[DaveH]

Looks like the resource leak was taking place in a broadcast message, not in the Attach code. Apparently, it is necessary to wait until all tables are open to start the OracleEvent Alerter. When we changed the timing of that startup, the problem went away. Why that should be involved, I don't know, but that weens to be the solution.

Dave

 

[Marco Kalter]

That's a curious solution to this problem...

------------------
Marco Kalter
Allround Automations