Atomicity problem / question

[Lars]

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

[Gary L. Burnore]

Re: Atomicity problem / question

On Fri, 4 Nov 2005 16:58:28 -0800, "Lars" <nobody@dev.nul l> wrote:
[color=blue]
>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.[/color]


One way: (There are surely many)


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.

--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
Official .sig, Accept no substitutes. | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ 0 1 7 2 3 / Ý³Þ 3 7 4 9 3 0 Û³
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
=============== =============== =============== =============== ===============

[Lars]

Re: Atomicity problem / question

> Make sure you have an auto-incrementing field. Insert an empty[color=blue]
> 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.[/color]

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

[Gary L. Burnore]

Re: Atomicity problem / question

On Fri, 4 Nov 2005 18:09:10 -0800, "Lars" <nobody@dev.nul l> wrote:
[color=blue][color=green]
>> 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.[/color]
>
>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?[/color]

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.

--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
Official .sig, Accept no substitutes. | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ 0 1 7 2 3 / Ý³Þ 3 7 4 9 3 0 Û³
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
=============== =============== =============== =============== ===============

[Lars]

Re: Atomicity problem / question

> I didn't say anything at all about a separate table.[color=blue]
>
> 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.[/color]

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

[Gary L. Burnore]

Re: Atomicity problem / question

On Fri, 4 Nov 2005 21:40:15 -0800, "Lars" <nobody@dev.nul l> wrote:
[color=blue][color=green]
>> 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.[/color]
>
>Ok. In my case, the table is for storing many different settings &
>configuratio n 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.
>[/color]

Right now you do a select for the "LastPONumb er", add one to it and
insert it. CHange the LastPONumber to autoincrementin g. Problem
solved.
--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
Official .sig, Accept no substitutes. | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ 0 1 7 2 3 / Ý³Þ 3 7 4 9 3 0 Û³
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
=============== =============== =============== =============== ===============

[Gordon Burditt]

Re: Atomicity problem / question

>>> I didn't say anything at all about a separate table.[color=blue][color=green][color=darkred]
>>>
>>> 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.[/color]
>>
>>Ok. In my case, the table is for storing many different settings &
>>configurati on 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 =
>>LastPONumbe r, 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.[/color][/color]

1. lock tables configuration_s ettings write;
2. update configuration_s ettings set Value=Value+1
where Category = 'ControlNumbers ' and Item = 'LastPONumber';
3. select Value from configuraton_se ttings
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.
[color=blue][color=green]
>>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.
>>[/color]
>
>Right now you do a select for the "LastPONumb er",[/color]

No, right now he does a select for Value where Category = 'ControlNumbers ' and
Item = 'LastPONumber'.
[color=blue]
>add one to it and
>insert it. CHange the LastPONumber to autoincrementin g.[/color]

You can't change Value in only one row to autoincrementin g.
[color=blue]
>Problem
>solved.[/color]

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

[Lars]

Re: Atomicity problem / question

> 1. lock tables configuration_s ettings write;[color=blue]
> 2. update configuration_s ettings set Value=Value+1
> where Category = 'ControlNumbers ' and Item = 'LastPONumber';
> 3. select Value from configuraton_se ttings
> where Category = 'ControlNumbers ' and Item = 'LastPONumber';
> /* Use Value as your PO number */
> 4. unlock tables;[/color]
[color=blue]
> If User A is in query 2 or 3, User B will wait at query 1 until User A
> finishes query 4.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> You also end up doing a lot of joins to get specific attributes
> (if present) in specific variables.[/color]
Out of curiosity, could you elaborate on this?

Thanks for your help,
Lars

[Gordon Burditt]

Re: Atomicity problem / question

>Thanks. That is more along the lines I was thinking, but I was not too happy[color=blue]
>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.[/color]

"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.
[color=blue][color=green]
>> 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.[/color]
>
>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.
>[color=green]
>> You also end up doing a lot of joins to get specific attributes
>> (if present) in specific variables.[/color]
>Out of curiosity, could you elaborate on this?[/color]

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, workstreetaddre ss, workcity, workstate,
workzip, workphone
FROM addrbook;

Gordon L. Burditt

[Gary L. Burnore]

Re: Atomicity problem / question

On Sat, 05 Nov 2005 16:11:48 -0000, gordonb.u4x7d@b urditt.org (Gordon
Burditt) wrote:
[color=blue]
>
>You can't change Value in only one row to autoincrementin g.[/color]

Where did you get that idea?
--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
Official .sig, Accept no substitutes. | ÝÛ³ºÝ³Þ³ºÝ³³ÝÛº ݳ޳ºÝ³Ý³Þ³ºÝ³Ý ÝÛ³
| ÝÛ 0 1 7 2 3 / Ý³Þ 3 7 4 9 3 0 Û³
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
=============== =============== =============== =============== ===============

[Lars]

Re: Atomicity problem / question

> "only a write lock" is a little like "only an atomic bomb".[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
>>> You also end up doing a lot of joins to get specific attributes
>>> (if present) in specific variables.[/color]
>>Out of curiosity, could you elaborate on this?[/color]
>
> 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';[/color]

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