in reply to Re (tilly) 3: DBI and table locking
in thread DBI and table locking

Obviously this is good advice in the general case, but it's slighly moot for the OP, who said he was on MySQL. It's impossible to get deadlock in MySQL as you have to declare all your locks at once .. declaring a new lock after that will free your current one.

Tony

  • Comment on Re: Re (tilly) 3: DBI and table locking

Replies are listed 'Best First'.
Re (tilly) 5: DBI and table locking
by tilly (Archbishop) on Jan 07, 2001 at 23:59 UTC
    Really?

    Remind me to avoid having to rely on MySQL for anything I care about then. Of course they don't understand ACID, which makes them a poor fit for a lot of areas. OTOH it gives them good performance, and it is "good enough" for many things.

    But the inflexible locking policy would be a problem for me.

[reply]

      Interesting. Bearing in mind the lack of transactions1, under what circumstances would you ever need to grab a lock on a second table having already taken a lock on a first table?

      Just curious. I've never encountered a need for this, and can't think of anything off-hand...

      Thanks,

      Tony

      1. yes, I know that recent MySQLs handle transactions.

[reply]
        Have you never noticed that a relational database that has locking is a way to manage locks across processes that are on several different machines and possibly operating systems?

        *grin*

        And AFAIK (*), what MySQL current calls transactions doesn't pass the ACID test. I tend to not like it when people use words that already have perfectly good meanings to mean something else...

        * I may be wrong on this. As you can tell, I don't use MySQL.

[reply]

In Section Seekers of Perl Wisdom