Re: LOCK TABLES using Perl in MySQL

Well, I made this great little application that writes to and updates a table in MySQL, but now I have more than one user making updates, and while I feel that the chance of a corruption is slim, I want to be able to lock the table for all other users(threads), write the information to the DB, then unlock the tables.
I am using DBD::mysql.

If you're just starting the design from scratch, it's probably easier to switch to PostgreSQL and get real transactions, and a lot more flexibility besides. Faster, Better, Cheaper. Pick all three.

For your application, there'd be no locking out other users while you're updating your values. Just a simple $dbh->begin_work, do your job, and then $dbh->commit. You could scribble all over many tables, and yet the other readers (not blocked) see the database just as if you didn't exist yet.

Real transactions are cool. Upgrade to PostgreSQL. MySQL is now pale in comparison.

-- Randal L. Schwartz, Perl hacker

Comment on Re: LOCK TABLES using Perl in MySQL Select or Download Code

Replies are listed 'Best First'.
Re: Re: LOCK TABLES using Perl in MySQL by mischief (Hermit) on Oct 13, 2001 at 17:27 UTC
How are PostgreSQL transactions more real than MySQL using the BerkeleyDB or InnoDB? I have to admit I'm not familiar with the differences, but I was under the impression that they were the same. Also, I think some people might not agree that PostgreSQL is faster than MySQL. And how is it cheaper? They're both free! I do agree that Postgres has more features though (missing subselects is almost unforgivable), but MySQL is catching up - apparently version 4.1 (which is scheduled to be out in a couple of months) will have subselects along with a load more features (secure connections! at last!).	[reply]
Re: Re: Re: LOCK TABLES using Perl in MySQL by merlyn (Sage) on Oct 13, 2001 at 19:42 UTC
How are PostgreSQL transactions more real than MySQL using the BerkeleyDB or InnoDB? I have to admit I'm not familiar with the differences, but I was under the impression that they were the same. After perusing the InnoDB/MySQL docs, I can see that MySQL is finally catching up. So I'll grant you that one, although it requires "strapping on" a completely separate solution from an independent vendor underneath, and that scares me. Also, I think some people might not agree that PostgreSQL is faster than MySQL. Did you notice the date on that benchmark? It's using Pg 7.0.2. I wouldn't have used anything prior to 7.1 either. Some more recent benchmarks put them in the same ballpark, with various tests showing one or the other ahead. And how is it cheaper? They're both free! Purchase price = $0. Installation time costs "money" though. I've always had to wrestle to install a MySQL distro from source. Pg installed trivially the first time. I was really amazed. And development time: with true views and subselects, you can do some amazing things, including putting business rules directly in the database, rather than having to code them in every application (and forgetting one, oops). Subselects, views, triggers, stored procedures. You don't miss them until you miss them, and then you wonder how you ever got along without them. So let me say it this way. MySQL is fine for people who are moving up from DBM. But once you've played with Oracle, Pg is the way to go. You sacrifice far too much of "typical" database coding with MySQL. Maybe someday MySQL will have everything in SQL 92. But Pg has that today. -- Randal L. Schwartz, Perl hacker	[reply]