A service I am working on has had a slow but sure increase of processor time each
hour and day, and I've been working to find why. It turns out I was leaking
TDBISAMSession objects. I'm posting this here so that others may have this as a
suggestion, and so that I can save myself time next time I make this mistake.

Executive summary: The Engine manages Sessions, and if you do not free them up,
they build up forever. This causes a slowdown after a while.

The key to this was that I had to change my session object management due to the
multi-threaded nature of the web server application. My applications have tended to
be heavily threaded, and a session per thread works fine. I adopted this for my web
use too, but it ended up with a single thread doing multiple actions for many
clients (thread pools) and having the session shared by everything was turning into
a mess. So I re-jigged it so that each activity created and free'd its own session.
Except I missed a free for one of them, an action called about once a second. But
running my test harness with leak checking showed no error.

I can only imagine that the slow down is due to the large number of sessions
causing a general longer time to do anything. The session number is managed by
TBits for example, which will run down the array for an open bit, so as more
sessions are leaked, more work is needed to find that empty bit.

The lack of a leak is because the Engine manages the list of sessions, and of
course will free any left over at the end.

To check that I don't fall over it again, I've added this check to the control
thread:
if Engine.SessionCount > 100 then
begin
LogReport(leError, '## SESSION LEAK ERROR ' +
  IntToStr(Engine.SessionCount));
end;

This isn't a big thing, and again I'm probably unusual in the use here - it isn't
normal to create and delete sessions every second. But it did fix my other issues,
and once the leak is fixed, it has been rock solid again.

/Matthew Jones/

Thanks for that - we've come to rely on FastMM reporting leaks (for
components with nil owners) so this is definitely a small concern for us
as well.
I don't think we leave any sessions dangling but now i need to go and
add some debug logging to check engine also just to be sure.

Raul



On 6/25/2013 4:27 AM, (Matthew Jones) wrote:
> Executive summary: The Engine manages Sessions, and if you do not free them up,
> they build up forever. This causes a slowdown after a while.

I've never had this issue before, and I suspect most people never will. And you'd
notice it with a slow creep up in processor use over time for an otherwise idle
process. It only happened because of my refactoring and thus breaking the normal
object disposal pattern I'd used.

Easy to check anyway - I figure no one will normally use 100 sessions, so
outputting an alert if such is reached will make someone think.

Also worth saying that I pondered whether anything should be added to DBISAM to
warn on this, but in the many years of reliable DBISAM service I've never had need,
so why now when I can spot it so easily myself, if needed.

/Matthew Jones/

I would prefer this to work like other runtime created delphi objects
(meaning if i call TDBISAMSession.Create(nil) then it will leak unless i
free it myself).

Raul

On 6/25/2013 10:05 AM, (Matthew Jones) wrote:
> Also worth saying that I pondered whether anything should be added to DBISAM to
> warn on this, but in the many years of reliable DBISAM service I've never had need,
> so why now when I can spot it so easily myself, if needed.
>
> /Matthew Jones/
>

> I would prefer this to work like other runtime created delphi
> objects (meaning if i call TDBISAMSession.Create(nil) then it will
> leak unless i free it myself).

It would be nice perhaps, but it would add complication to the existing stable code.
The key (I presume) is that some sessions are auto-created, so it would need to
manage the lifetimes of each in some way, and that then adds complexity. I'm not
sure it is worth the change.

/Matthew Jones/

It would be consistent which is more important IMHO. Also there should
be no impact to existing code - currently you free sessions when app
exists (and engine is freed) and with leak you leak memory when app
exits and can capture it if your mem manager supports it. Either way
there should be no impact to runtime code other than the bug you ran into.

I don't believe sessions are auto-created (other than the one default
session and that should have dbisam engine or application as owner or
such). Same is true for session on datamodule or form (they would have a
parent).

Hence the leak should only apply to sessions created with nil parent.

Let's see what Tim says is possible.

Raul

On 6/25/2013 12:33 PM, (Matthew Jones) wrote:
> It would be nice perhaps, but it would add complication to the existing stable code.
> The key (I presume) is that some sessions are auto-created, so it would need to
> manage the lifetimes of each in some way, and that then adds complexity. I'm not
> sure it is worth the change.

Matthew Jones wrote:

> if Engine.SessionCount > 100 then
> begin
>  LogReport(leError, '## SESSION LEAK ERROR ' +
>    IntToStr(Engine.SessionCount));
> end;

I'd like to thank myself for posting that back in 2013. Faced again
with a leak, I searched here to find myself telling me it was really in
my code, so go look harder. And I found my new leak. Well done me. 8-)

--

Matthew Jones

Matthew,

<< I'd like to thank myself for posting that back in 2013. Faced again with a leak, I searched here to find myself telling me it was really in my code, so go look harder. And I found my new leak. Well done me. 8-) >>

We really need to figure out a way to capitalize on all of this time travel that we've managed to accomplish recently....

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> We really need to figure out a way to capitalize on all of this time
> travel that we've managed to accomplish recently....

8-) Me, I find that I am capitalising by hitting these things again and
that saves me time. I've even found StackOverflow questions that I'd
asked years earlier and solved! So long as we have the internet, we
won't have to repeat things quite so much. Remember when we had to
learn things and look them up in books? That was an age ago.

--

Matthew Jones

Matthew

>. Remember when we had to
>learn things and look them up in books? That was an age ago.

All we should have done is replace books with the internet which simply speeds things up a bit. What seems to have happened in practice is lots of people no longer even bother trying to learn (ie internalise the knowledge and processes) or research or remember but simply ask the question again and again.

Roy