On 6/5/07, Baron Schwartz <baron@stripped> wrote:
> David T. Ashley wrote:
> > There is no concept that I'm missing. I understand what a transaction
> > But I just don't want to bothered. My application is simple enough that
> > bogarting the database until all necessary modifications have been made
> > 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?