Thanks Helen for good ideas. You raise one more day to work on that
issue with that long list :)

На Tue, 17 Oct 2006 09:15:45 +1000
Helen Borrie <helebor@...> написа:

>
> Things I would look at:
>
> 1. Is the ClientDataset thread-isolated? If it is in the main
> thread, then it is not...the Provider and the CDS must be in the same
> thread context..the safest way is to isolate everything in a
> datamodule that is created and destroyed by the thread.
>

I does not know that - will work on it.

> 2. Assuming the CDS is properly isolated, are you certain that all
> activity within the connection is complete before the thread is
> destroyed? (Events alerters and their notifications, fetches from
> the provider, stored procedures committed, etc.)
>

I do not destroy the thread. I am holding it in suspended state with
the idea to skip creating and connecting every time when I need to
reload that CDS. After I fetch all data in CDS my thread fire an event
to the main thread trough Synchronize method and then suspend.

> 3. Hopefully you are not trying to share an event alerter between
> multiple threads...
>

No. I do not work with events (from FB) at all :) for now.

> 4. Also check your DPR to make sure that the application startup is
> not creating an instance of the datamodule. (Yep, this is a "newbie"
> error but even experts forget sometimes!)
>

That is the hard part to explain. The application is a small exe which
have a lot of commands and all of the functionality is in several COM
DLLs. The problem zone (only one for now) is in one of these COM DLLs,
where I crate my form and it is create the datamodule. For now all the
CDSets are placed in that DataModule, except these MDODatabase and
MDOTransaction created in the thread class. Before that problem to came
up I have a serious problem with syncronizing threads at all. Because
in Delphi Synchronize method rely on window messaging and my form in
that DLL is modeless. It does not have message loop at all built-in
syncronization does not work at all. So I have to work around this with
catching Idle event in main application and transfer it to my DLLs
through COM interface methods. I am not 100% sure in my work around :)
but it seems to not affect the problem with connection because when my
form shows up it open several "important" DataSets from main thread in
parallel with my first (there will be at least 5-6 threads if I manage
to fix current problem) thread which open one "extra" DataSet. For now
- the extra thread finish its work much early before the main thread
finish opening its DataSets. So the extra thread just sits and wait to
my DLL get call from main application about Idle state - then DLL call
CheckSynchonize to deal with all waiting threads.

> 5. Does the log indicate whether the connection loss occurs on the
> client side or the server side? This might give some clues as to
> what is happening with the sockets.
>

I have just a quick look at the log now and it is fill with
"INET/inet_error: read errno = 104"
I have not explore that for now and last test was towards my Linux.
Today I will make more test against Windows FB Server where I am feel
more comfortable :) . Probably when I finish with isolating DataSets and
other components will check this log.

> 6. You're not trying to multi-thread local connections, are you? (I
> mean libfbembed.so or IPServer clients...)
>

No local connections.

Thanks again,
--
Miroslav Penchev