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

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.

Replies are listed 'Best First'.
Re: Re (tilly) 5: DBI and table locking
by salvadors (Pilgrim) on Jan 08, 2001 at 00:06 UTC

    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]

        I haven't really been following any of the discussion on BDB MySQL, but as far I can see, the only part of the ACID test that it fails now is Consistency. MySQL itself doesn't enforce any kind of integrity constraints, preferring to leave this up to the application.

        Whether or not this is actually a necessary condition of 'transactionness' is debatable IMO.

        Tony

[reply]

In Section Seekers of Perl Wisdom