"Helen Borrie" <helebor@...> skrev i melding
news:5.1.0.14.2.20030221005505.0308cff8@......

(I'm sorry, my OE crashes when I answer those messages, had to paste this
text into a new, fresh message)

> At 02:27 PM 20/02/2003 +0100, you wrote:
>
> > >
> > > At 11:19 20.02.2003 +0100, you wrote:
> > > >Q#2: How should I use transactions to avoid trouble and minimize need

for

> > > >database sweeps ?
> >
> >Yes. They explain much about handling transactions, but nothing about

what

> >to do if you need to change the Timeout stuff. It seems like I've fixed

it

> >by now, but only with a workaround that I really don't fancy.
> >Wouldn't a simple boolean property "UseTimeouts" or something like that

be

> >appropriate ?
>
> The *answer* to this question is in being able to time out a
> transaction. Or, to look at it from another angle, if you allow
> transactions to run indefinitely, you will get both trouble AND sweeps.

I don't need them to run indefinately, I just need to allow them to run for
more than 2 minutes, or avoid the transaction locking at the Api_Commit
call.
It was urgent to get around this, so I had to do a dirty source code
modification for now (Setting a longer interval in TIB_Transaction.Create).
This is no solution, but it works for now.

> You have a set of properties called TimeoutProps. Read the doc for
> TIB_TimeoutProps to see how to manipulate these settings.

The problem, obviously, is to be able to change settings in the *correct*
TimeoutProps. Or - more specific - to understand *what* the different
TIB_Transaction components are doing.
I believe I've figured out that I need to create an explicit transaction
component to use within the thread. I may be wrong about this. Now, it is
not *this* transaction that causes my problems, as it has its TimeoutProps
set to keep it from doing anything as long as a procedure is running. It's
the Internal Transaction, I believe.

> Did you manage to sort out your apparent confusion as to what a deadlock
> is? A deadlock isn't caused by a timeout, nor resolved by changing

timeout

> settings, as a rule, but by changing to a more suitable combination of
> isolation level and lockwait settings, such that an exception is returned
> to the client. It's my guess that (unless the engine is actually

returning

> a deadlock exception) you are getting a livelock, where your two worker
> threads are waiting for each other interminably. You *need* to get into a
> deadlock situation, so that your application can respond to the exception
> by rolling back the transaction in one thread in order to permit the other
> to commit.

"Deadlock" is a term also used with threads in a usual GUI application as
well. I've never heard about "livelock", but I wouldn't say that anyone
using different terms from me is "apparently confused".
First, I don't want any exception to be thrown, as there is nothing wrong.
Secondly, I don't need the transaction to perform any timeout actions, as I
know exactly when to do a commit, namely *after* the procedure is executed.
There is noone else messing with database when the procedures are run. No
user edits, no selects, no nothing.

> Another way to look at this is to ponder whether separating the tasks into
> separate transactions is actually serving your intentions. If one

activity

> is dependent on being able to "see" the new recversions created by the
> other, then both activities surely ought to be in the same transaction...

No, I don't need them to be separated into different transactions, only into
different threads. I'm not interested in the transactions stuff at all. Only
to make it work. If there was a way to make IB behave like Paradox (no
transactions whatsoever), id do so.

What is the best solution to my problem:

Main Thread:
----------------
1 connection to system database (sys.gdb)
1 connection to production database(prod.gdb)
- Need to be able to edit data in Prod database, but not while the thread is
running.
- Need to be able to select both from Sys and Prod databases while thread is
running.

Worker Thread:
-----------------
1 connection to system database (sys.gdb)
1 connection to production database(prod.gdb)
- Need to be able to select from Sys database while the thread is running.
- Need to create & drop tables, indices, procedures in Prod database.
(Metadata changes require reconnecting to ensure all changes being
visible, to my experience)
- Need to be able to insert/update/delete data (which is the sole purpose of
the application) in Prod database.

Worker Thread is created & controlled from Main Thread.
No data objects are passed between threads.

Any ideas ?

Thanks in advance !

--
Regards,

Bj�rge S�ther
bjorge@haha_itte.no