[drupal-devel] LOCK vs. SELECT FOR UPDATE

[Khalid B]

I can't comment on this history, but I think I understand why the
LOCK/REPLACE/UNLOCK was done.

The reason is to insure that the sequence you got has not been updated
by someone else, hence the REPLACE was enclosed in a LOCK/UNLOCK.

All this is not needed if we use AUTOINCREMENT fields, which as
someone else said, is available in the two supported databases, and
even in MS SQL should someone need it in the future.

This leaves only two other places where the tables are locked (one is
variable_set() and the other is cache_set() which are in
bootstrap.inc).

On 9/28/05, Gerhard Killesreiter <killesreiter at physik.uni-freiburg.de> wrote:
>
>
> On Wed, 28 Sep 2005, Robert Douglass wrote:
>
> > Moshe Weitzman wrote:
> >
> > > As for Gerhard's original question, it would certainly be nice to get
> > > rid of the requirement on LOCK TABLES permission. That has bit me before
> > > shared web hosts. Maybe we should use different locking technique
> > > depending on the table type or permission level of the DB user.
> > >
> >
> > That bit me on  a managed server (strato.de) One would think that if
> > you've got the entire server, managed or not, that you could count on
> > these features being there. I had to move the project to a root server
> > because of LOCK TABLES.
>
> I've searched a bit about when and why we introduced locking in the first
> place:
>
> http://lists.drupal.org/archives/drupal-devel/2002-08/msg00222.html
> http://lists.drupal.org/archives/drupal-devel/2002-09/msg00087.html
> http://lists.drupal.org/archives/drupal-devel/2002-08/msg00243.html
>
> It still does no explain why we need(ed?) to have the ID before the
> commit. Does anybody recall this?
>
> Cheers,
>         Gerhard
>