Subject | Re: [IBO] TIBODatabase and multithreading |
---|---|
Author | Helen Borrie |
Post date | 2006-09-27T01:50:47Z |
Hello Piotr,
At 03:32 AM 27/09/2006, you wrote:
firebird-support, I now think that the distinct instance of the
TIBODatabase creates its own IB_Session. The component itself
doesn't expose an IB_Session property at all, as its ancestors do.
The **really important thing** is to make sure that you create a
fully self-contained instance of your datamodule for EACH thread
instance and that you destroy it when the thread completes. You will
get these cross-overs and AVs if your main thread is trying to access
objects created by this thread-specific module.
Within this self-contained data module, give the IBODatabase a
distinctive name, such as DBThread, and take care to set the
IB_Connection to this, rather than leaving it as <default>. I
recommend this, as it will quickly reveal whether you have
something around that is causing defaults to conflict and cross
over. Unless you are using specific IBOTransaction or IB_Transaction
components, you can safely let the other controls find the default
transaction that is wrapped into the module's IBODatabase instance.
In summary,
1. Do not mix components for the main thread and the ad hoc threads
on the same datamodule.
2. Make certain that all components in the datamodules have the
appropriate Creation Order - make it a rule to check this always and
to correct it, if necessary. (The TIBODatabase should be the first.)
3. Explicitly set the IB_Connection property of all statements.
4. Check your Project Source. Make certain that you have commented
out the Create statement for the datamodule that you are going to use
for the threads.
5. Do not use cpLocal as the Protocol for the TIBODatabase that is
in the datamodule you are going to use for the threads. Use cpTCP_IP
and fill the Server property appropriately (Localhost or 127.0.0.1 if
the application and the database server are on the same host machine).
6. Another precaution is to clear out any Params entries that might
be lingering in the thread's IBODatabase at design-time. Make your
application refer to the Server, Path and Protocol properties directly.
There may be more configuration issues to consider. In future
postings, please try to be specific about the messages you are seeing
when something blows up.
Helen
At 03:32 AM 27/09/2006, you wrote:
>Hello,Actually, contrary to what I suggested to your original posting in
>
>I have a big trouble with my application. I get lot's of AV in
>fbclient.dll and some other strange errors that seem to be result of
>some kind of mistake I made in making my app threadsafe. I was
>searching all over the documentation and the internet for days but
>couldn find an answer nowhere....
>
>My Application uses 4 threads connected to DB. Each one of them has
>its own datamodule, TIBODatabase and TIB_Session obcject (first in
>creation order). I use cpTCP_IP connection to the FB2.0RC4 server.
>IBO4.6Bc.
>
>Isn't TIBODatabase + IB_Session enough to make a fbclient.dll thread safe?
firebird-support, I now think that the distinct instance of the
TIBODatabase creates its own IB_Session. The component itself
doesn't expose an IB_Session property at all, as its ancestors do.
The **really important thing** is to make sure that you create a
fully self-contained instance of your datamodule for EACH thread
instance and that you destroy it when the thread completes. You will
get these cross-overs and AVs if your main thread is trying to access
objects created by this thread-specific module.
Within this self-contained data module, give the IBODatabase a
distinctive name, such as DBThread, and take care to set the
IB_Connection to this, rather than leaving it as <default>. I
recommend this, as it will quickly reveal whether you have
something around that is causing defaults to conflict and cross
over. Unless you are using specific IBOTransaction or IB_Transaction
components, you can safely let the other controls find the default
transaction that is wrapped into the module's IBODatabase instance.
In summary,
1. Do not mix components for the main thread and the ad hoc threads
on the same datamodule.
2. Make certain that all components in the datamodules have the
appropriate Creation Order - make it a rule to check this always and
to correct it, if necessary. (The TIBODatabase should be the first.)
3. Explicitly set the IB_Connection property of all statements.
4. Check your Project Source. Make certain that you have commented
out the Create statement for the datamodule that you are going to use
for the threads.
5. Do not use cpLocal as the Protocol for the TIBODatabase that is
in the datamodule you are going to use for the threads. Use cpTCP_IP
and fill the Server property appropriately (Localhost or 127.0.0.1 if
the application and the database server are on the same host machine).
6. Another precaution is to clear out any Params entries that might
be lingering in the thread's IBODatabase at design-time. Make your
application refer to the Server, Path and Protocol properties directly.
There may be more configuration issues to consider. In future
postings, please try to be specific about the messages you are seeing
when something blows up.
Helen