Hi,

I know that I need a new session/database in a thread and the thing is
that one can not (obviously) safely use the same component(s) across
threads. That is clear. But ...

I have a pool for Indy components and now I'd like to replicate some
code (optimizing an application) and write a dbisam connections pool
manager.

That being said, I'd like to reuse the session/database when a thread
finishes its job and a different one needs to do different work on the
same database (why close the session, connect again, blah-blah, doesn't
make much sense). So I was curious if the GetCurrentThreadID is used in
dbisam sources and found that it is used (from my understanding of the
sources) only for remote connections! In other words, my project might
work when not using remote sessions and not work otherwise. Which kind
of again doesn't make sense. Why does the server code need to know the
thread id for a session?

Am I missing something here?
Can someone tell me if what I want is possible?

--
TIA,
Lucian

Lucian,

<< That being said, I'd like to reuse the session/database when a thread
finishes its job and a different one needs to do different work on the same
database (why close the session, connect again, blah-blah, doesn't make much
sense). So I was curious if the GetCurrentThreadID is used in dbisam sources
and found that it is used (from my understanding of the sources) only for
remote connections! In other words, my project might work when not using
remote sessions and not work otherwise. Which kind of again doesn't make
sense. Why does the server code need to know the thread id for a session? >>

It's a security/stability design to ensure that a different thread doesn't
try to reconnect to a session being used by a different thread.  Doing so
could cause some serious issues.

You can take out that code if you need to.  It's right here in the
dbisamsv.pas unit:

function TDataServer.ReconnectServerSession(SessionThread: TServerThread;
                                           SessionToReconnect:
TServerSession;
                                           var WaitForDisconnect: Boolean):
Boolean;
begin
  LockServerSessions;
  try
     WaitForDisconnect:=False;
     Result:=False;
     if (FServerSessions.IndexOf(SessionToReconnect) <> -1) then
        begin
        if (AnsiCompareText(SessionThread.ClientProcess,
                            SessionToReconnect.UserProcess)=0) and
           (SessionThread.ClientThread=SessionToReconnect.UserThread) then
           begin

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks, I'll check that out

--
Lucian

> doesn't try to reconnect to a session being used by a different
> thread.  Doing so could cause some serious issues.
>
> You can take out that code if you need to.  It's right here in the
> dbisamsv.pas unit:
>
> function TDataServer.ReconnectServerSession(SessionThread:
> TServerThread;
> SessionToReconnect: TServerSession;
> var WaitForDisconnect: Boolean): Boolean; begin
>   LockServerSessions;
>   try
>      WaitForDisconnect:=False;
>      Result:=False;
>      if (FServerSessions.IndexOf(SessionToReconnect) <> -1) then
>         begin
>         if (AnsiCompareText(SessionThread.ClientProcess,
>                             SessionToReconnect.UserProcess)=0) and
>            (SessionThread.ClientThread=SessionToReconnect.UserThread)
> then            begin



--