[TYPO3-dev] Duplicate entry on cache_pagesection on reloading twice

[Ivan Gomez Rodriguez]

Manuel Rego Casasnovas wrote:
> Hello,
> 
> El mié, 20-02-2008 a las 15:31 +0100, Moreno Feltscher escribió:
>> Does this works with dbal? "ON DUPLICATE KEY UPDATE" would be a risk
>> in this case..
> 
> I don't know if it works with dbal. You can use it since MySQL 3.23 [1].
> 
> On the other hand, at the moment there is an important concurrence
> problem at line 385 in [2].
> 
> The problematic lines:
> 384: $GLOBALS['TYPO3_DB']->exec_UPDATEquery('cache_pagesection',
> 'page_id=' . intval($GLOBALS['TSFE']->id) . ' AND mpvar_hash=' .
> $mpvar_hash, $dbFields);
> 385: if ($GLOBALS['TYPO3_DB']->sql_affected_rows() == 0) {
> 386:    $dbFields['page_id'] = intval($GLOBALS['TSFE']->id);
> 387:    $dbFields['mpvar_hash'] = $mpvar_hash;
> 388:    $GLOBALS['TYPO3_DB']->exec_INSERTquery('cache_pagesection',
> $dbFields);
> 389: }
> 
> The problem happens when two process try to do the UPDATE and its can't
> do it. Then both process go into if and try to do two INSERT with the
> same key.
> 
> This problem could happen with more than 2 process.

Well , this solution is better than previous one cause this one doesn't
depend on DB, but I want to remark *the importance of that bug*.

We develop portals with a high number of posible users and those kind
of *problems of concurrence* could be a big problem in those situations.

It is assumed that Typo3 is content management system for *enterprise
purposes* and *problems of concurrence* are not acceptable in no way

I know that php is a very limited language and free DB systems has some
limitation related to transactions, etc.

But I insist *problems of concurrence* are not acceptable in no way.

For each client request a php process is launched and several process
 running in the server in the normal situation.

All of those process do *inserts or updates or selects on the same DB*
and it's very important be careful with that.

Previously solutions for this bug *apparently works* because the patches
introduces more code between lines and that *reduce the risk* but it
*doesn't solve nothing*.

Sorry if I too hard in this mail but this bug is very very important and
I hope that no more bugs like this apperas in new features or extensions
, you mus be very carefull with concurrency and if you never listen
nothing about concurrency it's important that you know what is and how
could we avoid problems in order to avoid problems like this one in the
future.

http://en.wikipedia.org/wiki/Concurrency_(computer_science)
http://dev.mysql.com/books/mysqlpress/mysql-tutorial/ch10.html
...


-- 
Iván Gómez Rodríguez
Computer Science Engineer
mailto:igomez at igalia.com
Igalia http://www.igalia.com