NYCPHP Meetup

[David Mintz]

On Tue, 24 Feb 2004, Tim Gales wrote:

> [...]
> This link will not immediately answer the
> question you're asking.[...]
> http://www.bridgeport.edu/sed/projects/cs503/Spring_2001/kode/os/sync.htm
>
> I would suggest you compare 'locks' with 'semaphores' there.
>
> Many operating system mechanisms are quite re-usable in applications.
>


Thanks for tip Tim. I've just read it and plan to re-read it.


> I would like to know where you read:
> "I've read that you should either lock tables or use transactions"

Maybe I oversimplified, and I don't mean to put words in anyone's mouth.
But there was this: "Obviously, you need to read the last_update value and
have your UPDATE occur with no other updates sneaking in between them. If
you're using InnoDB tables, use a transaction, otherwise, lock the table
for writing before you read the last_update value and then unlock it after
you either write the new data or decide that you can't write because it's
changed." in
<http://lists.nyphp.org/pipermail/talk/2003-December/006718.html>, and
there's a discussion in MySQL by Paul Dubois (2nd Ed; Sam's; pp 238 et
seq) that seems to imply that one either locks tables or uses
transactions. And I have some other books lying around... I'll spare you
the rest of the bibliography.


>
> I think there are times when you want to lock down a table in part
> of a transaction -- i.e. do both.
>

Most respectfully, I agree (-: I believe my scenario is a case in point.


> When you start locking stuff down in transactions, it is beneficial to
> have some mechanism in place to avoid 'race' conditions.
> (see the above link for ideas on that)

Thanks again.




---
David Mintz
http://davidmintz.org/

        "Anybody else got a problem with Webistics?" -- Sopranos 24:17