Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
Memory tables used by multiple threads |
Thu, Feb 9 2006 7:34 PM | Permanent Link |
Oliver Bock | I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept
shown below. It appears that DeleteAllPasswords is trying to use a TList that has already been destroyed. It only happens when I create a memory TDBISAMTable in a second thread for the same client. It does not happen if it is not a memory table, and there is no problem in the first thread that attaches to the server. I create the TDBISAMTable as follows: t := TDBISAMTable.Create(nil); t.SessionName := fDB.SessionName; t.DatabaseName := 'Memory' t.TableName := table_name; Am I doing this right? I note that there is no way for this table to find the TDBISAMDatabase (fDB) for this thread because I only tell it "Memory". Perhaps it associates a single Memory TDBISAMDatabase with both threads and then tries to free it twice? 0046c5c5 Classes 2827 TList.Get 00668bac dbisamen TDataSession.DeleteAllPasswords 00667d19 dbisamen TDataSession.Destroy 00404670 system 8385 TObject.Free 00662e24 dbisamen TDataEngine.FreeDataSessions 0065a42d dbisamen TDataEngine.Destroy 00404670 system 8385 TObject.Free 006b0449 dbisamtb TDBISAMEngine.FreeInstance 00404a32 system 9060 @ClassDestroy 0047987a Classes 9759 TComponent.Destroy 00404670 system 8385 TObject.Free 006c336a dbisamtb Finalization 0040519c system 10704 FinalizeUnits 0044d79c madExcept InterceptFinalizeUnits 00405475 system 11374 @Halt0 0093094f ArtfulLedger 336 initialization |
Thu, Feb 9 2006 7:39 PM | Permanent Link |
Oliver Bock | Oliver Bock wrote:
> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept > shown below. It appears that DeleteAllPasswords is trying to use a > TList that has already been destroyed. I should have added that my code is executing on the server in a server procedure. It is using the session provided by OnServerProcedure and creating a separate TDBISAMDatabase (fDB) for each thread. Oliver |
Fri, Feb 10 2006 3:59 AM | Permanent Link |
"Frans van Daalen" | "Oliver Bock" <oliver-elevatesoft-news@ikucwe.com> wrote in message news:BB4722A7-FC96-4DDA-882C-6632C5D06B9D@news.elevatesoft.com... > Oliver Bock wrote: >> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept >> shown below. It appears that DeleteAllPasswords is trying to use a TList >> that has already been destroyed. > > I should have added that my code is executing on the server in a server > procedure. It is using the session provided by OnServerProcedure and > creating a separate TDBISAMDatabase (fDB) for each thread. > > You need an unique session per thread as well http://www.elevatesoft.com/dbisam4d5_multi_threaded_applications.htm |
Fri, Feb 10 2006 2:50 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Oliver,
<< It only happens when I create a memory TDBISAMTable in a second thread for the same client. It does not happen if it is not a memory table, and there is no problem in the first thread that attaches to the server. >> What do you mean by "second thread" ? Do you mean the second session that is connected to the database server ? If so, then it shouldn't matter since the two don't use the same session and should not interfere with one another. Or are you sharing resources in the server procedure across multiple sessions ? -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Feb 12 2006 6:14 PM | Permanent Link |
Oliver Bock | Frans van Daalen wrote:
> "Oliver Bock" <oliver-elevatesoft-news@ikucwe.com> wrote in message > news:BB4722A7-FC96-4DDA-882C-6632C5D06B9D@news.elevatesoft.com... >> Oliver Bock wrote: >>> I'm getting a crash in DBISAM 4.22b4 with the stack trace from madExcept >>> shown below. It appears that DeleteAllPasswords is trying to use a TList >>> that has already been destroyed. >> I should have added that my code is executing on the server in a server >> procedure. It is using the session provided by OnServerProcedure and >> creating a separate TDBISAMDatabase (fDB) for each thread. >> >> > You need an unique session per thread as well > http://www.elevatesoft.com/dbisam4d5_multi_threaded_applications.htm Hi Frans, I create a separate session for each thread at the client end, and DBISAM takes care of creating matching sessions on the server. Oliver |
Sun, Feb 12 2006 6:20 PM | Permanent Link |
Oliver Bock | Tim Young [Elevate Software] wrote:
> Oliver, > > << It only happens when I create a memory TDBISAMTable in a second thread > for the same client. It does not happen if it is not a memory table, and > there is no problem in the first thread that attaches to the server. >> > > What do you mean by "second thread" ? Do you mean the second session that > is connected to the database server ? If so, then it shouldn't matter since > the two don't use the same session and should not interfere with one > another. Or are you sharing resources in the server procedure across > multiple sessions ? Yes, sorry, I meant a second session (in a second thread) connected to the database server. As far as I know, there is no sharing of resources across multiple sessions. According to the manual: > ...all TDBISAMDatabase components must also be unique and have their SessionName properties referring to the unique SessionName property of the TDBISAMSession component defined in the manner discussed above. I guess my question boils down to this: if threads should have separate instances of any TDBISAMDatabases they use, then who takes care to ensure there are separate instances of the hidden "Memory" TDBISAMDatabase? I was wondering whether my problem might be related to this discrepancy. Oliver |
Mon, Feb 13 2006 11:26 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Oliver,
<< I guess my question boils down to this: if threads should have separate instances of any TDBISAMDatabases they use, then who takes care to ensure there are separate instances of the hidden "Memory" TDBISAMDatabase? I was wondering whether my problem might be related to this discrepancy. >> DBISAM takes care of that, so as long as you have the SessionName property hooked up correctly for the table or query components, then there won't be an issue. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Feb 16 2006 1:55 AM | Permanent Link |
Oliver Bock | Tim,
After much effort I've managed to reduce this to a very simple client/server demonstration with no threads, which I'll send to you via a bug report. For the record, I get a crash when: CLIENT 1. Create a session. 2. Create a database. 3. Use a TDBISAMQuery to create a memory table. 4. Call a server procedure. 9. Destroy objects and exit. SERVER (must be using FastMM 4.58 with full debug mode) 5. Receive the server procedure call. 6. Creates a TDBISAMDatabase using the session provided as a param. 7. Open a TDBISAMTable using the memory table. 8. Destroy the TDBISAMTable and TDBISAMDatabase. 10. Exit and crash. |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |