At 01:38 PM 3/11/2003 +0000, you wrote:

>Here is some further information: This problem has been found on
>both the Win2K and Linux Superserver platforms (for the database
>server). We are using dbExpress data access components. The
>database configuration has automatic housekeeping disabled (0),

And you are doing manual sweeps instead?

>Forced Writes turned off,

There's a big chunk of memory growth. Do you realise that, on your Win2K
server, none of your database changes will ever get written to disk until
you DO a server shutdown? The Linux server should be OK with FW off but I
hope you've got a UPS with lots of minutes. You have backversions piling
up in memory too.

Why do you think you need FW off?

>4K page size and 16384 pages. Connections
>are pooled (on average, around 5 simultaneous connections found).
>There is only one UDF registered (strlen from IB_UDF), but it is not
>used currently.
>
>Other observable behavior includes: at the start of the working
>day, the clients often encounter the dbExpress error "duplicate
>transaction id". This seems unlikely, though,

How are the connections being made? via localhost (local loopback) or
using local connect?
Since you're pooling connections, are you testing them for InTransaction
before dropping the connection?
if MyDbConnection.InTransaction then
MyDbConnection.Rollback;

Could be something going on with dropout clients, maybe. Could the
connections be going back into the pool too soon because you're assuming
that, once the client disconnects, the connection is available? This won't
be the case if the transaction is still pulling rows into the buffer in the
WebModule.

>since the database
>connection component is dropped on the Webmodule (there is,
>therefore, only one connection per thread) and the transaction is
>started in the OnBeforeDispatch of the WebModule (before handling
>the user's request) and committed (if an exception did not
>necessitate a rollback in between) in the OnAfterDispatch.

If you're pulling large datasets, commit or rollback won't be
instantaneous. Also make sure you're not relying on Autocommit to get you
out of trouble if the client just simply decides to surf off somewhere.

>Also, once every two days or so (and always in working hours) the FB
>server terminates abnormally, with only "inet_error"s 104 and 110
>taking up the rest of the FB log. These errors do not occur
>directly before the server terminating, though, and are from the
>Linux SS server.

Those could be "wanderers" - flotsam and jetsam left behind from clients
disappearing without hitting the Submit button.

>How could I go about finding out what's wrong? Which diagnostic
>steps could you suggest? Your help is much appreciated.

Enable FW on the Win2K server for starters so you're not building a big fat
heap of backversions in memory and risking losses in the event of a server
crash. Reduce the number of rows in queries so the connections get freed
up in a timely fashion. Make sure a connection really *is* available
before releasing it to the pool. Sweep. Put a timer in the webapp to
detect neglected webmodule instances.

One or more of the above, probably.