At 02:05 PM 15-09-00 -0400, you wrote:

>I unsuccessfully tried to recreate the problem. However, I did notice that
>interserver.exe seems to use a lot of memory when there are a large number
>of sql statements executed on a connection.
>
>The following code makes interserver.exe go to 31MB ram (according to win2k
>task manager). The memory is released when the connection is closed and the
>interserver.exe process ends.
>for i = 1 to 10000 {
> create statement
> statement.execute sql
> close statement
>}

In practice, you would never do this. You would set up the statement
first, start a transaction, prepare the statement, go into your loop,
iterate right through the loop and commit the transaction at the end. The
effect of doing what the above code describes is to make the gap between
the OAT (oldest active transaction) and the current transaction ever
wider. That is what eats CPU time.

>I was going to use interbase as the backend for a servlet web system - and
>implement a simple connection pooling class. This makes it look like only
>one statement should be created per connection - and the statement should be
>cached in the pool with the connection. It looks like the statement memory
>is never getting cleaned up in interserver.exe.

Are you sure that it is interserver that is eating the resources? It looks
more like a problem of garbage accumulation in the database server. Having
thousands of uncommitted transactions sitting inside this looping process
completely prevents garbage collection.

As a rule of thumb, if you have an OAT gap which is greater than twice the
number of connections, you really need to take a serious look at the
architecture of your application...

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
___________________________________________________
Project JEDI · http://delphi-jedi.org
___________________________________________________