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.