PHP/MySQL Synchronous innoDB queries works as asynchronous - php

Question

I need to update and read data from one table at the same time with different PHP scripts.
I create $sess as script session identifier (works around 20 scripts at same time) and I set in the table row the session identifier for 100 rows. After, it will SELECT rows reserved for this script by session identifier. In the while loop the script will do some work with the data and update reserved rows.
But the scripts don't work at same time, the first script works fine, but others not do first query while the first script is running. I see it in my database management app.
$sess = intval(str_replace(".", "", microtime(TRUE)));
sql_query("UPDATE locations SET sess='$sess' WHERE sess='0' LIMIT 100");
$r = sql_query("SELECT * FROM locations WHERE sess='$sess'");
while ($q = sql_row($r))
{
Create table syntax
CREATE TABLE `locations` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`country_id` int(11) unsigned DEFAULT NULL,
`area_id` int(11) unsigned DEFAULT NULL,
`timeZone` int(2) DEFAULT NULL,
`lat` double DEFAULT NULL,
`lon` double DEFAULT NULL,
`locationKey` int(11) unsigned DEFAULT NULL,
`cityId` int(11) unsigned DEFAULT NULL,
`sess` bigint(100) unsigned DEFAULT '0',
PRIMARY KEY (`id`),
KEY `lat` (`lat`),
KEY `lon` (`lon`),
KEY `country_id` (`country_id`),
KEY `cityId` (`cityId`),
KEY `area_id` (`area_id`),
KEY `sess` (`sess`)
) ENGINE=InnoDB AUTO_INCREMENT=3369269 DEFAULT CHARSET=utf8;

Answer 1

Are you inside a transaction (BEGIN...COMMIT)? If so, you have locked those 100 rows. Ditto for autocommit=0.
Instead, be sure the UPDATE (which is used to assign 100 items from your 'queue' to your process) is in a transaction by itself.
Then, assuming the other threads cannot call microtime in the same microsecond (a dubious assumption), the 100 items are safely assigned to you. Then you can start another transaction (if needed) and process them.
However, that 100-row SELECT will unnecessarily put a read lock on those rows.
So...
START TRANSACTION;
UPDATE ... LIMIT 100;
SELECT ...
COMMIT;
foreach ...
START TRANSACTION;
work on one item
COMMIT;
end-for
It is unclear whether the second START-COMMIT should be inside the for loop or outside. Inside will be slower, but may be 'correct', depending on what "work" you are doing and how long it could take. (You don't want to ROLLBACK 99 successful 'works' because the 100th took too long.)
Are you later doing DELETE ... WHERE sess = $sess? If you are mass-deleting like that, then do it in a separate transaction after the for loop.
Goal: segregate the queuing transactions from the application transactions.
Note that the segregation will make it easier to code for errors/deadlocks/etc. (You are checking, correct?)