Race condition when inserting data / MySQL 4.0+, MyISAM tables

[Markus]

Hello

I use a table to cache some informations which need lots of resources to
be composed. The first time the info is needed, it will be composed and
written to the cache table ($db in the example is a PEAR DB object; the
question is the same for other ways of accessing the database):

// Retrieve info if present
$details = $db->getOne("SELECT contents FROM cache WHERE id=".$id." AND
info='details'");
// If not present, compose info and write it to the database
if (!is_string($details) || trim($details) == '') {
$details = $this->compose_details();
$data = array('id' =$id, 'info' ='details', 'contents' =$details);
$db->query("INSERT INTO cache (id, info, contents) VALUES (".$id.",
'details', '".$details."')");
}

Now I encountered that if several users call a page at the same time
after the cache was flushed, it is possible that between the first line
and the INSERT query the info was entered by another user. This results
in a duplicate key error.

Now I wonder which is the best way to handle this. I see various approaches:
- Use ON DUPLICATE KEY UPDATE (which might fail if MySQL 4.0 is used)
- Try to write some kind of locking mechanism
- Suppress the error message for this special case
- Remove the primary key from the cache table (as it is flushed whenever
items are administrated, duplicate entries might not be a big problem)

Which is the recommended way to handle this? I guess, as MySQL 4.0 and
MyISAM tables are a quite common configuration, there must be some
common practice about this, but I did not find anything by googling...

Thanks for comments!
Markus

[Michael Fesser]

..oO(Markus)

>[handling a race condition]

Which is the recommended way to handle this? I guess, as MySQL 4.0 and
MyISAM tables are a quite common configuration, there must be some
common practice about this, but I did not find anything by googling...

Is it really necessary to keep the script compatible to outdated
versions of MySQL? The current stable is 5, the old 4.0 is not even
available for download anymore. If it still has to work on a series 4
server, then I would make at least 4.1 a requirement.

I would even drop support for MyISAM and use InnoDB instead, but that's
just a personal decision. I simply need the features of a modern engine,
so I can't take care of older installations. The same goes for PHP for
example -- my scripts require PHP 5.2, PHP 4 is dead (it's official
now). At some point you simply have to draw the line.

Micha

[Markus]

Michael Fesser schrieb:

.oO(Markus)

>[handling a race condition]

Which is the recommended way to handle this? I guess, as MySQL 4.0 and
MyISAM tables are a quite common configuration, there must be some
common practice about this, but I did not find anything by googling...

Is it really necessary to keep the script compatible to outdated
versions of MySQL? The current stable is 5, the old 4.0 is not even
available for download anymore. If it still has to work on a series 4
server, then I would make at least 4.1 a requirement.

I would even drop support for MyISAM and use InnoDB instead, but that's
just a personal decision. I simply need the features of a modern engine,
so I can't take care of older installations. The same goes for PHP for
example -- my scripts require PHP 5.2, PHP 4 is dead (it's official
now). At some point you simply have to draw the line.

Thank you, I see the point; anyway the application is supposed to work
with shared hosting, where MySQL 4.0 is still around. Though, dropping
4.0 support is actually an issue - also because it is not natively
supporting UTF-8. And I use MyISAM simply because it is the only engine
that provides fulltext search.

[Michael Fesser]

..oO(Markus)

>And I use MyISAM simply because it is the only engine
that provides fulltext search.

OK, that's one point for MyISAM. But my own focus is on data integrity
(most important: foreign keys and transactions), so that's not an issue
here.

Micha

[petersprc]

With MyISAM, you can do one of the methods you described or use LOCK
TABLES.

In your case I would do ON DUPLICATE KEY UPDATE or remove the unique
constraint on the id.

Finally, if you need to prevent more than one thread from executing
the generate function, you can use a semaphore with the key being your
id.

On Jul 13, 10:28 am, Markus <derernst@NO#SP#AMgmx.chwrote:

Hello

I use a table to cache some informations which need lots of resources to
be composed. The first time the info is needed, it will be composed and
written to the cache table ($db in the example is a PEAR DB object; the
question is the same for other ways of accessing the database):

// Retrieve info if present
$details = $db->getOne("SELECT contents FROM cache WHERE id=".$id." AND
info='details'");
// If not present, compose info and write it to the database
if (!is_string($details) || trim($details) == '') {
$details = $this->compose_details();
$data = array('id' =$id, 'info' ='details', 'contents' =$details);
$db->query("INSERT INTO cache (id, info, contents) VALUES (".$id.",
'details', '".$details."')");

}

Now I encountered that if several users call a page at the same time
after the cache was flushed, it is possible that between the first line
and the INSERT query the info was entered by another user. This results
in a duplicate key error.

Now I wonder which is the best way to handle this. I see various approaches:
- Use ON DUPLICATE KEY UPDATE (which might fail if MySQL 4.0 is used)
- Try to write some kind of locking mechanism
- Suppress the error message for this special case
- Remove the primary key from the cache table (as it is flushed whenever
items are administrated, duplicate entries might not be a big problem)

Which is the recommended way to handle this? I guess, as MySQL 4.0 and
MyISAM tables are a quite common configuration, there must be some
common practice about this, but I did not find anything by googling...

Thanks for comments!
Markus