On 16 Jan 2003, Ron Johnson wrote:
> On Thu, 2003-01-16 at 09:39, Andrew Sullivan wrote:
> > On Thu, Jan 16, 2003 at 08:34:38AM -0600, Ron Johnson wrote:
> > > On Thu, 2003-01-16 at 08:20, Andrew Sullivan wrote:
> >
> > > > If a user has multiple connections and charges things to the same
> > > > account in more than one connection at the same time, the
> > > > transactions will have to be processed, effectively, in series: each
> > > > one will have to wait for another to commit in order to complete.
> > >
> > > This is true even though the default transaction mode is
> > > READ COMMITTED?
> >
> > Yes. Remember, _both_ of these are doing SELECT. . .FOR UPDATE.
> > Which means they both try to lock the corresponding record. But they
> > can't _both_ lock the same record; that's what the lock prevents.
>
> Could BEFORE INSERT|UPDATE|DELETE triggers perform the same
> functionality while touching only the desired records, thus
> decreasing conflict?
It does limit it to the corresponding records, but if you
say insert a row pointing at customer 1, and in another transaction
insert a row pointing at customer 1, the second waits on the first.