Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Issue with simultaneous MySQL actions

by Anonymous Monk
on Jul 31, 2003 at 20:07 UTC ( [id://279759]=note: print w/replies, xml ) Need Help??


in reply to Issue with simultaneous MySQL actions

$dbh = DBI->connect("dbi:mysql:db","","") or die "Error db1";

$sth = $dbh->prepare("select max(id) from tracker where agent='abc'");
$sth->execute;
$newid = $sth->fetchrow_array;
$sth->finish;

if($newid eq '') { $newid = 1; }
else { $newid++; }

$msubject = $fr{subject}; $msubject =~ s/\'/\\'/g;

$sth = $dbh->prepare("insert into tracker values ( 'abc', $newid, '$msubject', '$todaydate', '$emailto', $sntcount, 0, 'eCard', '' )");
$sth->execute;
$sth->finish;

$dbh->disconnect;


That is the code... How come it doesn't write simultaneously? Any ideas?
  • Comment on Re: Issue with simultaneous MySQL actions

Replies are listed 'Best First'.
Re: Re: Issue with simultaneous MySQL actions
by chromatic (Archbishop) on Jul 31, 2003 at 20:14 UTC

    There's a possibility it's being overwritten, since you're generating your row ids by hand. You could lock the table while you're doing the insert, which is usually a bad idea. You could wrap the whole transaction in a transaction, if you're using MySQL 4.x (people who want to complain and bandy about the phrase "ACID", go waste your life in Slashdot discussions; you guys bore me, at best).

    I'd rather make the id column AUTO_INCREMENT, though, in which case you don't have to insert anything and it generates a unique ID automatically.

    Other possibilities are that your uploaded file is hitting a resource limit or that your server disallows multiple CGI programs to run simultaneously. This really feels like a concurrency issue, though.

Re: Re: Issue with simultaneous MySQL actions
by sgifford (Prior) on Jul 31, 2003 at 21:16 UTC
    That code has a race condition that could explain the trouble you're having. Here's an example.
    1. prog1 executes the select statement. max(id) is currently 3.
    2. prog 2 executes the select statement. max(id) is still 3.
    3. prog1 finishes out the code, incrementing id and then inserting all of the information for record with id 4.
    4. prog2 finishes out the code, incrementing id and then inserting all of the information for record with id 4.

    Depending on how your system is set up, the result could be that the second request is rejected (you don't do any error checking in your example, so you'd never know) or that both are inserted, and you only look at the first one your query returns (for example, in your sample select statement, you just ignore any additional rows that the query returns).

    The solution is what chromatic suggested---make this action atomic somehow. Use an auto_increment variable, lock the table, or incorporate finding the ID into the SQL statement. As a kludgey alternative, require that the id column be distinct, then catch the error resulting from your insert statement, and get the new biggest id and try again.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://279759]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2024-04-19 06:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found