On 14 Mar 2007, at 18:02, Michael Dykman wrote:
SELECT * from process WHERE WHERE id = 123 AND status = 'init' FOR
UPDATE;
-- do a bunch of other stuff ...
UPDATE process SET status = 'ready' WHERE id = 123 AND status =
'init';
I get what you're doing here, but I don't see why it's necessary -
the update will automatically acquire locks on matched rows while
it's doing the update - at least that's the impression I've had from
the docs:
"A SELECT ... FOR UPDATE reads the latest available data, setting
exclusive locks on each row it reads. Thus, it sets the same locks a
searched SQL UPDATE would set on the rows."
"UPDATE ... WHERE ... sets an exclusive next-key lock on every record
the search encounters."
So it sounds like the select for update will effectively be the same
as what I'm already doing, and thus suffer the same problem.
Is it just that locks don't apply outside the transaction? If
transactions can't solve synchronisation problems between processes,
what are they for??!
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of [EMAIL PROTECTED] CRM solutions
[EMAIL PROTECTED] | http://www.synchromedia.co.uk/
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
