Re: Unique index behavior question

Myron is correct on this one.

Daniel's answer reflects a very common misunderstanding: when manipulating data you get "first come, first served" only in the sense that whoever tries to manipulate a row first, gets a lock on it. All others have to stand in line waiting until this first operation has been committed or rolled back. Their operation doesn't even start before then. In other words, the database server will never present sessions that subsequently try to modify locked data with the illusion that their requests have been fulfilled when in fact it can't be sure whether it will ever be in a position to do so.

And that is exactly what you really want it to do in order to keep things simple and clean. Think about it, I'm sure you'll come to the same conclusion.

Cheers,
Christian Sage

"Frank LaRosa" <frank_at_franklarosa.com> schrieb im Newsbeitrag news:3ABB8BEA.6095B262_at_franklarosa.com...
> Let's say a table has a column, call it A, that has a unique index on
> it.
>
> Client 1 and client 2 start transactions. Client 1 adds or updates a row
> in the table with a particular value for column A. Then, client 2 tries
> to add or update a different row using the same value for column A, and
> does so before client 1 commits its transaction.
>
> Will client 2 receive an immediate error when it attempts to make its
> change, or will the error occur when the clients commit their
> transactions? Will the last client that commits receive the error, or
> the last client to perform the update?
>
Received on Mon Mar 26 2001 - 15:49:40 CST