[TYPO3-core] RFC: Bug 4581: Duplicate entry on cache_pagesection on reloading twice

Dmitry Dulepov dmitry at typo3.org
Wed Jan 24 15:27:24 CET 2007


Hi!

Ingmar Schlecht wrote:
> Did you closely read Oliver's description? I think it sounds very
> reasonable, what he's saying.

I did :) It works for a limited case: solves only INSERT after UPDATE 
problem but it does not solve problem with double INSERTs completely. It 
works in assumption that only one client is trying to access this table. 
This is not so in real life.

> Without Oliver's patch:
> (1) UPDATE -> succeeds
> (2) UPDATE -> succeeds, but TYPO3 thinks it didn't because
>               mysql_affected_rows() == 0
> (2) INSERT -> fails
> 
> With Oliver's patch:
> (1) UPDATE -> succeeds
> (2) UPDATE -> succeeds, and TYPO3 knows that it succeeds because
>               $sql_info['rowsmatched'] == 1

Not like this but like this:

(client 1) UPDATE - fail because record does not exist
(client 1) mysql_info() - no such row
(client 2) UPDATE - fail due to the same reason
(client 2) INSERT - success
(client 1) INSERT - fail because #2 already inserted row

This is typical multithreading behaviour. You cannot assume that nothing 
changes between calls to mysql_info() and INSERT. Another thread may 
take control in the middle and modify database. mysql_info will tell you 
that there is nothing there but after that and before you try to insert, 
another client may successfully insert the same data. Thus this solution 
will not work in highly loaded multithreaded environment.

If you have only one client at a time running that code, yes, Oliver's 
solution will be excellent. But we still will have error messages on 
real servers even after applying his patch (though less often).

-- 
Dmitry Dulepov

Web: http://typo3bloke.net/
Skype: callto:liels_bugs

"It is our choices, that show what we truly are,
far more than our abilities." (A.P.W.B.D.)


More information about the TYPO3-team-core mailing list