> Well I assume the db uses a lot of stack memory by traversing indices
> in the btree, and many other fb operational functions - but maybe 300
> MB isn't reasonable. It's just that I can't control how fb uses
> memory doing these types of things. I wonder if I can...

It depends on number of the connections you have. Prepare, please, a
test case and I can check the allocations in debugger...

But you're right - you don't have direct control over this. If you would
have hard limits there, some of your connections would fail with "Out of
memory" error.

So the real way is to find out how many memory is used by one connection
during the typical usage and then plan your parallel connections using
this number.

Your goal is to make the incoming requests to your application server
(Tomcat, for example) to stall in the incoming queue - this is the
pattern to which most browsers and applications are used to. This is
done by tuning the number of worker threads in the server - it should be
equal to your desired memory footprint.

Other patters might cause different timeouts in different places (e.g.
when getting connection from the pool), which is harder to cope with.

Roman