Atomicity problem / question

Hi,

I need a way to read a numeric field and then increment it by one in such a
way that even if two users did this at the exact same time, they would still
each get their own unique value. I would prefer a method not requiring me
to lock the whole table.

What is the best way to accomplish this?

I am using MySQL 3.23.58 and I use an ISAM type database.

Thanks,
Lars

> Make sure you have an auto-incrementing field. Insert an empty
> record, return the new incremented value to the user.
>
> Next user inserts next record, gets next key.
>
> Once they've completed their input, do an update to the empty record
> using he auto-incremented number.

Thanks for your reply.

Your method would probably work, but I was not totally clear in my original
post: I am looking for is a cleaner method. I would prefer not having to
have a separate table just for generating a unique value (or, rather, one
table for each type of unique value).

Something like this would work if I could lock the record:

UPDATE table SET field = field + 1 WHERE whatever
SELECT field from table WHERE whatever

Short of using a table lock or switching to InnoDB, what is the best way to
accomplish this?

Thanks,
Lars

> I didn't say anything at all about a separate table.
>
> The method I mentioned is quite clean. One table, you simply insert
> the entire row with nothing in the other fields to get it to give you
> the auto-incremented value then use said value to key the update.

Ok. In my case, the table is for storing many different settings &
configuration options. It has the following columns: Category, Item &
Value. Most of the records in the table have nothing to do with unique
values, but a few of them do. E.g. Category = ControlNumbers, Item =
LastPONumber, Value = 1000

If user A and user B simultaneously request the next invoice number, one
should get 1001, the other 1002 and the LastPONumber field will be 1002
afterwards.

If I understand your approach correctly, I would either have to add an
auto-incremented field to this table, or have an extra table just for this
purpose.

Lars

>>> I didn't say anything at all about a separate table.
>>>
>>> The method I mentioned is quite clean. One table, you simply insert
>>> the entire row with nothing in the other fields to get it to give you
>>> the auto-incremented value then use said value to key the update.
>>
>>Ok. In my case, the table is for storing many different settings &
>>configuration options. It has the following columns: Category, Item &
>>Value. Most of the records in the table have nothing to do with unique
>>values, but a few of them do. E.g. Category = ControlNumbers, Item =
>>LastPONumber, Value = 1000
>>
>>If user A and user B simultaneously request the next invoice number, one
>>should get 1001, the other 1002 and the LastPONumber field will be 1002
>>afterwards.

1. lock tables configuration_settings write;
2. update configuration_settings set Value=Value+1
where Category = 'ControlNumbers' and Item = 'LastPONumber';
3. select Value from configuraton_settings
where Category = 'ControlNumbers' and Item = 'LastPONumber';
/* Use Value as your PO number */
4. unlock tables;

If User A is in query 2 or 3, User B will wait at query 1 until User A
finishes query 4.

>>If I understand your approach correctly, I would either have to add an
>>auto-incremented field to this table, or have an extra table just for this
>>purpose.
>>
>
>Right now you do a select for the "LastPONumber",

No, right now he does a select for Value where Category = 'ControlNumbers' and
Item = 'LastPONumber'.

>add one to it and
>insert it. CHange the LastPONumber to autoincrementing.

You can't change Value in only one row to autoincrementing.

>Problem
>solved.

There's a lot of utility in a Keyword = Value approach. For instance,
for an address book application, you might have a table: PersonID,
Attribute, and Value. Attribute might be things like 'First Name',
'Birth Date', 'Home Fax Number', 'Work Email', 'Home Street Address',
etc. You can add more without having to change the schema.
The trouble is, what type is Value? It's got dates, names,
telephone numbers, email addresses, etc. in it. You also end up
doing a lot of joins to get specific attributes (if present) in
specific variables.

Gordon L. Burditt

> 1. lock tables configuration_settings write;
> 2. update configuration_settings set Value=Value+1
> where Category = 'ControlNumbers' and Item = 'LastPONumber';
> 3. select Value from configuraton_settings
> where Category = 'ControlNumbers' and Item = 'LastPONumber';
> /* Use Value as your PO number */
> 4. unlock tables;

> If User A is in query 2 or 3, User B will wait at query 1 until User A
> finishes query 4.

Thanks. That is more along the lines I was thinking, but I was not too happy
about a table-level locking since the table is accessed very heavily by many
users. In real life I don't think it would be a problem, though, since it
is only a write lock and only for a split second at a time.

> There's a lot of utility in a Keyword = Value approach. For instance,
> for an address book application, you might have a table: PersonID,
> Attribute, and Value. Attribute might be things like 'First Name',
> 'Birth Date', 'Home Fax Number', 'Work Email', 'Home Street Address',
> etc. You can add more without having to change the schema.
> The trouble is, what type is Value? It's got dates, names,
> telephone numbers, email addresses, etc. in it.

I find the approach quite flexible for my purposes, since a text field can
store most any type of data. The job of ensuring proper format of dates,
numbers, etc. lie with the business objects of my apps.

> You also end up doing a lot of joins to get specific attributes
> (if present) in specific variables.
Out of curiosity, could you elaborate on this?

Thanks for your help,
Lars

>Thanks. That is more along the lines I was thinking, but I was not too happy
>about a table-level locking since the table is accessed very heavily by many
>users. In real life I don't think it would be a problem, though, since it
>is only a write lock and only for a split second at a time.

"only a write lock" is a little like "only an atomic bomb".
A write lock prevents others from accessing AT ALL; a read
lock prevents others from writing. But what you need here is
a write lock.

>> There's a lot of utility in a Keyword = Value approach. For instance,
>> for an address book application, you might have a table: PersonID,
>> Attribute, and Value. Attribute might be things like 'First Name',
>> 'Birth Date', 'Home Fax Number', 'Work Email', 'Home Street Address',
>> etc. You can add more without having to change the schema.
>> The trouble is, what type is Value? It's got dates, names,
>> telephone numbers, email addresses, etc. in it.
>
>I find the approach quite flexible for my purposes, since a text field can
>store most any type of data. The job of ensuring proper format of dates,
>numbers, etc. lie with the business objects of my apps.
>
>> You also end up doing a lot of joins to get specific attributes
>> (if present) in specific variables.
>Out of curiosity, could you elaborate on this?

A query for printing business cards with the keyword = value
organization might look like:

SELECT a.value, b.value, c.value, d.value, e.value, f.value, g.value
FROM addrbook a
LEFT JOIN addrbook b on a.personid = b.personid and b.attribute = 'Last Name'
LEFT JOIN addrbook c on a.personid = c.personid and c.attribute = 'Work Street Address'
LEFT JOIN addrbook d on a.personid = d.personid and d.attribute = 'Work City'
LEFT JOIN addrbook e on a.personid = e.personid and e.attribute = 'Work State'
LEFT JOIN addrbook f on a.personid = f.personid and f.attribute = 'Work Zip'
LEFT JOIN addrbook g on a.personid = g.personid and g.attribute = 'Work Phone'
WHERE a.attribute = 'First Name';

(personid, attribute) is a primary key so lookups should be fast,
but it still joins 7 copies of the table. Attribute is a good
candidate for an enum if you're willing to have to change the schema
to add new ones. The corresponding query with a table with a column
for each attribute might be:

SELECT firstname, lastname, workstreetaddress, workcity, workstate,
workzip, workphone
FROM addrbook;

Gordon L. Burditt

> "only a write lock" is a little like "only an atomic bomb".
> A write lock prevents others from accessing AT ALL; a read
> lock prevents others from writing. But what you need here is
> a write lock.

Oh, I had that backwards. That may not work too well, then. Probably a
separate table to hold these unique numbers would be a better approach after
all, since it would not interfere with the access to the rest of the
settings in the table.

>>> You also end up doing a lot of joins to get specific attributes
>>> (if present) in specific variables.
>>Out of curiosity, could you elaborate on this?
>
> A query for printing business cards with the keyword = value
> organization might look like:
>
> SELECT a.value, b.value, c.value, d.value, e.value, f.value, g.value
> FROM addrbook a
> LEFT JOIN addrbook b on a.personid = b.personid and b.attribute = 'Last
> Name'
> LEFT JOIN addrbook c on a.personid = c.personid and c.attribute = 'Work
> Street Address'
> LEFT JOIN addrbook d on a.personid = d.personid and d.attribute = 'Work
> City'
> LEFT JOIN addrbook e on a.personid = e.personid and e.attribute = 'Work
> State'
> LEFT JOIN addrbook f on a.personid = f.personid and f.attribute = 'Work
> Zip'
> LEFT JOIN addrbook g on a.personid = g.personid and g.attribute = 'Work
> Phone'
> WHERE a.attribute = 'First Name';

I got it. No, this is not at all what I use that kind of tables for. The
Item, Value approach I use only for storing settings & resources, etc.

Thanks,
Lars