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