The difference here, is that any row locked via the SELECT .. FOR UPDATE will not even allows readers access to that record until, so you will not have processes concurrently trrying to process. This means that, for each row, any processes acting on it are force to be seqential each each subsequent phase needs to wait for the previous one to complete.
- michael On 3/14/07, Marcus Bointon <[EMAIL PROTECTED]> wrote:
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/
-- - michael dykman - [EMAIL PROTECTED] - All models are wrong. Some models are useful. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
