You mention the need to change metadata - if you are doing this
on a "live" database then you can probably expect problems. Nothing
to do with threads - just trouble in and of itself.


Its been a while, but the last time I looked transaction timeouts
did not operate in background threads, only on the main thread.
In background threads it is up to you to ensure they do not run
too long. If timeouts are firing in your background thread then
you may need to check that you are creating your thread components
correctly - specifically attached to the separate thread ib_session.

In the foreground thread you can prevent timeouts either by changing
the properties OR simply by changing the isolation to concurrency
(which is the default isolation) on those transactions you dont want
effected (and then ensuring that you have processing to ensure they
dont stay active too long).


Is it safe to presume that you have looked at the threading demo
to see how to create the separate IB_Session component in the
background thread - and create the thread components using that
session (and not the default/main-thread ib_session) ???

My experience was that the best approach was to be very specific
when creating thread components - making completely certain they
were attaching to the thread ib_session.


Is it safe to presume that you know you must NOT use local
connections in multi-threaded apps? (TCP/IP localhost is OK,
but not the cpLocal protocol.)


Yes you do need to pass objects between threads (or at least I found
that it was necessary) - in order to be able to provide appropriate
feedback to the user when errors occur in the background thread.


You mention that you think it may be an internal transaction causing
you problems - presumably you are thinking of the transaction that
is internal to the connection (for retrieving of metadata etc),
since there should be no other transactions active if you are
creating your own explicit ones. You are not using the connection
SchemaCacheDir property are you? (Since I can imagine this causing
problems if used from both main and alternate threads.)


And last of all - I cant see see where/how you have determined the
source of the problem. This is always difficult with threaded apps,
but perhaps you can run some experiments to find the specific point
of failure. eg: Have each thread writing debug messages to its own
file, attaching event code to the various points to write such
messages so you can be sure of where the problem is coming from.


--
Geoff Worboys
Telesis Computing