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

[Oliver Hader]

Hi Ivan,

Ivan Gomez Rodriguez schrieb:
> Manuel Rego Casasnovas wrote:
>> 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

Thanks for your investigation. But there's no need to *shout* and to 
devalue others! Politeness is something different...
For TYPO3 4.2 there were some major changes concerning these concurrent 
scenarios:
#5152: "Duplicate entry" in cache_pagesection when using frames [1]
-> rewriting affected parts to prevent concurrent DB modifications
#7333: Better solution for "Page is being generated" [2]
-> introducing a locking mechanism to prevent concurrent caching of the 
same content

You can test these changes with TYPO3 4.2-beta1a and should use the 
post-patch from the bugtracker [2] "0007333_post_v2.patch".

olly

Links:
[1] http://bugs.typo3.org/view.php?id=5152
[2] http://bugs.typo3.org/view.php?id=7333
-- 
Oliver Hader
http://inpublica.de/