At 06:15 PM 11/13/2001 +0200, Ilmars Knipshis wrote:

>If you
>make 2 transactions: let say from 1. IBconsole "update A set values
>..." and then without commit from 2. IBconsole "update A set values
>...". Second transaction is on deadlock and waiting. So it's OK. Then
>make commit from 1.IBconsole. Immediately you will receive error
>message from 2.console.
>
>Is it error or feature?

I believe it is a feature, but it is a feature you can avoid. The
reason I think it is a feature is that a transaction should see a
consistent view of the database. Within a transaction you should
be able to count, sum, or average values and get the same result
each time. In that mode, the second update transaction can't see
the results of the first update - they aren't committed when it
starts its operation. A transaction can't update what it can't see.

In heavy contention, having the second transaction wait for the
outcome of the first avoids some unnecessary rollbacks. If the
first transaction had rolled back, the second would succeed.

However, the rest of the world considers consistency to be a
bore. For them, there is a transaction mode called read committed
which will behave like DB2. (SET TRANSACTION READ COMMITTED)


Regards,

Ann
www.ibphoenix.com
We have answers.