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

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.

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

Replies are listed 'Best First'.
Re (tilly) 7: DBI and table locking
by tilly (Archbishop) on Jan 08, 2001 at 00:16 UTC
    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]
        I agree with tilly. This all boils down to use. For a lot of web based sites MySQL works fine. It's free and unlike a major RDBMS doesn't require a DBA life support team (ie boring people like me :-). However, for a full blown application with multiple concurrent users with a complicated Database design, MySQL cannot be considered as a serious choice. Aside from whats been mentioned above, such as the lack of Database procs, It doesn't scale so well and the fundamental SQL is restricted for example Update statements cannot have a from clause (ANSI SQL'92 compliant but functionally very restrictive).
[reply]

In Section Seekers of Perl Wisdom