Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 3 of 3 total |
thread safety issue |
Fri, Jan 25 2008 1:24 PM | Permanent Link |
"Lucian Radulescu" | 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 |
Mon, Jan 28 2008 2:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Jan 28 2008 5:42 PM | Permanent Link |
"Lucian Radulescu" | 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 -- |
This web page was last updated on Thursday, April 18, 2024 at 10:42 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |