[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