Professional Web Applications Themes

Atomicity problem / question - MySQL

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...

  1. #1

    Default 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


    Lars Guest

  2. #2

    Default Re: Atomicity problem / question

    > 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


    Lars Guest

  3. #3

    Default Re: Atomicity problem / question

    > 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




    Lars Guest

  4. #4

    Default Re: Atomicity problem / question

    >>> 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
    Gordon Burditt Guest

  5. #5

    Default Re: Atomicity problem / question

    > 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





    Lars Guest

  6. #6

    Default Re: Atomicity problem / question

    >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
    Gordon Burditt Guest

  7. #7

    Default Re: Atomicity problem / question

    > "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


    Lars Guest

Similar Threads

  1. CSS IE problem and navigation bar question
    By mfv84 in forum Macromedia Dynamic HTML
    Replies: 6
    Last Post: September 10th, 10:52 PM
  2. another gradient printing problem question
    By parker@adobeforums.com in forum Adobe Illustrator Macintosh
    Replies: 3
    Last Post: May 11th, 06:48 PM
  3. PS 8 or OS X problem? Also rip Question
    By zoozx@adobeforums.com in forum Adobe Photoshop Mac CS, CS2 & CS3
    Replies: 0
    Last Post: February 18th, 09:29 PM
  4. form problem/question
    By Stijn Goris in forum PHP Development
    Replies: 2
    Last Post: November 14th, 04:15 PM
  5. A question to Lex problem
    By Geoff Liu in forum UNIX Programming
    Replies: 2
    Last Post: July 2nd, 01:19 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139