>
> Hi again,
>
> I'm trying to use your hint, but I don't find the new select sintax in the
> docs, so excuse me for asking again.
> If I've got it right, whe I make a SELECT ... FOR UPDATE within a connection
> (Autocommit = off), the selected records are blocked until the connection is
> closed, commited or rolled-back. Thus, only the same transaction can modify
> them, and consistency is thus achieved.
>
> I've tried lauching two processes that make simultaneous updates on one
> table (different rows) and simultaneous inserts on another (these processes
> are client order imports from file). One of the processes run while the
> other kept waiting in the first insert it atempted. Do I have to use any SQL
> or configure something, or is this the normal behaviour?
>
> Thanks again for your answers.
I assume you are running the snapshot, and not 6.4.*. You are actually
using FOR UPDATE, so I think it is the snapshot.
This is normal behavior, I think. I believe the issue with SELECT FOR
UPDATE is that it has to lock the entire table. We allow non-blocking
readers and non-blocking writers on different rows by using the
transaction id and multi-version system. SELECT FOR UPDATE does not
actually modify any rows, so we can't look at any transaction id.
Vadim, can you comment?
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026