Subject | Re: [firebird-support] Re: Transaction Deadlock |
---|---|
Author | Slalom |
Post date | 2007-01-12T16:23:18Z |
Thanks for the input Helen,
This kind if isolation sounds like exaclty what I need. Different users are upating different pieces of the record.
----- Original Message ----
From: Helen Borrie <helebor@...>
To: firebird-support@yahoogroups.com
Sent: Thursday, January 11, 2007 8:27:46 PM
Subject: Re: [firebird-support] Re: Transaction Deadlock
At 12:04 PM 12/01/2007, you wrote:
"appropriate" for your situation, where you want to permit
indiscriminate overwriting of one user's work by another's.
Transaction isolation is all about keeping the database in a
consistent state while allowing individual transactions to behave as
though they were the only transaction. It is the application' s
responsibility to manage its transactions and this certainly includes
intercepting lock conflicts and handling them in a healthy manner.
The one "loose" area is when you have Read Committed isolation with
the RECORD_VERSION flag and WAIT resolution policy: in that case,
instead of excepting with the original conflict, the challenger will
wait until the conflicting record version is committed and then overwrite it.
This is *almost* a dirty read/write situation: it's the one
configuration where proper transaction isolation is at risk. Don't
use it unless you *seriously* want your transactions to overwrite one
another's changes unconditionally. Certainly don't use it if your
only intention is to avoid handling exceptions in your apps!
./heLen
[Non-text portions of this message have been removed]
This kind if isolation sounds like exaclty what I need. Different users are upating different pieces of the record.
----- Original Message ----
From: Helen Borrie <helebor@...>
To: firebird-support@yahoogroups.com
Sent: Thursday, January 11, 2007 8:27:46 PM
Subject: Re: [firebird-support] Re: Transaction Deadlock
At 12:04 PM 12/01/2007, you wrote:
>I've changed my params to:Depends what you deem "appropriate" . It may be that it is
>
>read_committed
>rec_version
>wait
>
>Is this isolation appropriate for multi-thread, multi-client read/write
>access?
"appropriate" for your situation, where you want to permit
indiscriminate overwriting of one user's work by another's.
Transaction isolation is all about keeping the database in a
consistent state while allowing individual transactions to behave as
though they were the only transaction. It is the application' s
responsibility to manage its transactions and this certainly includes
intercepting lock conflicts and handling them in a healthy manner.
The one "loose" area is when you have Read Committed isolation with
the RECORD_VERSION flag and WAIT resolution policy: in that case,
instead of excepting with the original conflict, the challenger will
wait until the conflicting record version is committed and then overwrite it.
This is *almost* a dirty read/write situation: it's the one
configuration where proper transaction isolation is at risk. Don't
use it unless you *seriously* want your transactions to overwrite one
another's changes unconditionally. Certainly don't use it if your
only intention is to avoid handling exceptions in your apps!
./heLen
[Non-text portions of this message have been removed]