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.