Subject | Re: [ib-support] trouble with multi threading |
---|---|
Author | Claudio Valderrama C. |
Post date | 2002-02-13T07:58:44Z |
""M Patterson (Multinail)"" <mpatterson@...> wrote in
message
news:004401c1b397$b8f23840$1164a8c0@......
threads. It's possible to debug where the second thread stalls in your app
to know what to blame at least.
You need separate sessions => separate connections.
Make sure the isolation level is either repeatable read (snapshot,
concurrency) or read committed, depending on your needs. If it's RC, then
don't use "no wait" with "no record_version". In fact, never use "no
record_version" under normal operations. Make sure your app doesn't have a
conflict when accessing the GUI part from two threads. I assume your query
is a SELECT, not an update that can have conflicts in the engine with the
first thread. Don't go to the extreme of reserving tables for the
transactions unless you know what you are doing with such advanced feature.
Etc.
Have you tried a simple case with datasets that don't have a datasource
neither visual controls attached? You could put a BEEP after the call to
OPEN or ACTIVE to see if the command returned or is stalled, since you won't
have visual feedback.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing
message
news:004401c1b397$b8f23840$1164a8c0@......
>query,
> It runs fine in one thread, but when the second goes to open its first
> the app freezes.And have you tried to debug? I understand that you are are using two
> Do you have any other ideas?
threads. It's possible to debug where the second thread stalls in your app
to know what to blame at least.
You need separate sessions => separate connections.
Make sure the isolation level is either repeatable read (snapshot,
concurrency) or read committed, depending on your needs. If it's RC, then
don't use "no wait" with "no record_version". In fact, never use "no
record_version" under normal operations. Make sure your app doesn't have a
conflict when accessing the GUI part from two threads. I assume your query
is a SELECT, not an update that can have conflicts in the engine with the
first thread. Don't go to the extreme of reserving tables for the
transactions unless you know what you are doing with such advanced feature.
Etc.
Have you tried a simple case with datasets that don't have a datasource
neither visual controls attached? You could put a BEEP after the call to
OPEN or ACTIVE to see if the command returned or is stalled, since you won't
have visual feedback.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing