At 04:50 AM 30/08/2007, you wrote:

>Hello All,
>
> I have developed a web application using Delphi 7, Intraweb 8.0.22,
>IBO 4, & Firebird 1.5.
>
>I am having an issue with my app not being thread-safe and I'm pretty
>sure its in my data access. I did not realize until reading the IBO
>FAQ that a TIB_Session was necessary to make the data access portion
>of the app thread-safe. I have added a TIB_Session to my datamodule
>and move it to be first in the creation order. I wanted to clarify
>and make sure that is all I need to do. I was confused by a couple
>responses post by Jason in the IBO FAQ:
>
>"You need not only a connection for each thread but it is also a good
>idea to have a TIB_Session for each thread. When the connection,
>transaction and dataset components are created, make the session their
>owner. This isolates each thread from other thread contexts.
>
>If you do this then IBO is fully thread-safe."
>
>and
>
>"One thing to ensure is that each thread needs to create a TIB_Session
>component. Then, when you create the other components, like the
>TIB_Connection, make that TIB_Session instance the owner of the other
>IBO components the thread uses.
>
>Make sure the TIB_Session is FIRST in the creation order."
>
>
>Like I said before, I have added a TIB_Session to my datamodule and
>moved it to first in the creation list.

And you are creating and destroying that datamodule for each thread
instance, right?

>What is meant by "when you
>create the other components, like the TIB_Connection, make that
>TIB_Session instance the owner of the other IBO components the thread
>uses." ? Do I have more coding to do or is this automatically handled
>by adding the TIB_Session to the datamodule and moving it to first in
>the creation order? If I do have more coding to do, what would the
>code look like?

It depends.

In the IDE, as soon as you drop an IBO component anywhere (including
a TIB_ control), IBO automatically creates an IB_Session internally
for the main thread, if it does not already have one. That becomes
the default session and every IBO object thereafter (except other
IB_Session objects) will be owned by that session.

If you are creating a DM for creation and destruction for use by a
thread, you need an explicit IB_Session for it. That one will be
owned by the DM. Any objects you add to the DM in the IDE, you will
have to assign their IB_Session property to *that* session.

>There is no code resembling this assignment of the session as the
>owner of the other IBO components in the Threads sample application?

You would do this assignment in code if you were doing the whole
create and destroy thing at run-time, rather than pre-packaging it at
design-time. There would be nothing out-of-the-ordinary about
this: simply a matter of doing the whole thing in the right order.

I use the McDonalds analogy to explain data access thread
safety. You have the main thread (the McDonalds store). You have
the menu up above the service counter, listing all the culinary
delights - these are the various classes that you have set up (in the
IDE or in run-time code) to produce the hamburger. Behind each meal
choice is a "datamodule" - a cardboard ring enclosing a bun (the
ib_session), the meat item (ib_connection and ib_transaction) plus a
number of other components, such as cheese, veges and dressing, that
give the meal its special character.

Now, when you go and order your meal, you expect that you will pay
for it, pick it up, take it away and execute your particular
McDonalds thread without competition from other hamburger thread
executors, i.e., any attempt by another HTE to access your bun, meat,
vegies, dressing in order to consume their hamburgers would cause an
access violation.

Helen