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.

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

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.

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...

Helen


Helen