Hello Ann,

Thank you, for responce.

Tuesday, November 13, 2001, 8:58:24 PM, you wrote:

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

We tested "SET TRANSACTION READ COMMITTED" mode, and it gave us the same
result. Is it any other sugestions?




AWH> 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?

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

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


AWH> Regards,

AWH> Ann
AWH> www.ibphoenix.com
AWH> We have answers.


AWH> Yahoo! Groups Sponsor
AWH> To unsubscribe from this group, send an email to:
AWH> ib-support-unsubscribe@egroups.com



AWH> Your use of Yahoo! Groups is subject to theYahoo! Terms of Service.




--
Regards,
Ilmars mailto:ilmars@...