On 6/5/07, Baron Schwartz <[EMAIL PROTECTED]> wrote:

David T. Ashley wrote:
> There is no concept that I'm missing.  I understand what a transaction
is.
> But I just don't want to bothered.  My application is simple enough that
> bogarting the database until all necessary modifications have been made
and
> the tables are again consistent is good enough.
>
> Collisions are handled by serialization.  Period.  Somebody
wins.  Everyone
> else waits.  Works for me.

Then the simplest possible thing to do (besides using transactions, which
IMO would
actually be a LOT less bother!) is use GET_LOCK('database_name').  That
should handle
your requirement to make locks 'database-local.'

In my experience, using LOCK TABLES becomes a spaghetti problem that
begins to involve
more and more things until you are going through *serious* contortions.  I
would avoid
it at all costs.


My only concern with GET_LOCK() is that lock is server-global rather than
database-global.  This makes attacks possible in a shared setting (some bad
person could disable your database code by going after your lock).

My solution is just to lock all tables in one statement.

The only question I have (and nobody has answered this) is how many tables I
can include in a single LOCK TABLE statement.  I thinking anything up to a
few thousand shouldn't be a problem.  What is the limit?

Thanks, Dave.

Reply via email to