Have you considered splitting the different pieces of the record into
different tables? That way, you would avoid the kind of update conflict
that you describe and at the same time avoid the danger of a person
actually updating a field that he doesn't know the current value of.

Set

Slalom wrote:

> 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:
>> I've changed my params to:
>>
>> read_committed
>> rec_version
>> wait
>>
>> Is this isolation appropriate for multi-thread, multi-client read/write
>> access?
>
> Depends what you deem "appropriate" . It may be that it is
> "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