I think you're missing the concept of a transaction in the database sense.
The idea behind a transaction is that you can perform multiple steps and if
you don't complete all steps, any changes are reversed. The reversal process
is handled by the database.
A good example is moving money from bank
On 6/5/07, Brent Baisley [EMAIL PROTECTED] wrote:
I think you're missing the concept of a transaction in the database sense.
The idea behind a transaction is that you can perform multiple steps and if
you don't complete all steps, any changes are reversed. The reversal process
is handled by the
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.
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
Hi David,
On Jun 5, 2007, at 3:55 PM, David T. Ashley wrote:
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
I decided to go with a simple paradigm for my web-based database. Rather
than transactions, each process locks the entire database while it is
changing something, then unlocks it. This just serializes access (all other
processes will block until the one modifying the database has finished).
David T. Ashley wrote:
I decided to go with a simple paradigm for my web-based database. Rather
than transactions, each process locks the entire database while it is
changing something, then unlocks it. This just serializes access (all
other
processes will block until the one modifying the
On 6/4/07, Gerald L. Clark [EMAIL PROTECTED] wrote:
David T. Ashley wrote:
LOCK TABLE thistable, thattable, theothertable,
goshthislistcangetlongtable;
Do whatever is needed;
UNLOCK TABLES;
You could use a string lock for this.
Thanks for the suggestion. It looks logically correct.
www.the-infoshop.com
www.giiexpress.com
www.etudes-marche.com
-Original Message-
From: David T. Ashley [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2007 3:54 PM
To: mysql@lists.mysql.com
Subject: Re: Lock Tables Question
On 6/4/07, Gerald L. Clark [EMAIL PROTECTED] wrote
On 6/4/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
Whatever you do, make sure that every bit of code that locks multiple
resources locks them in the same order. That's the only way to avoid
deadlocks.
Hi Jerry,
I really appreciate the good advice.
However, my original question is still
David T. Ashley wrote:
On 6/4/07, Jerry Schwartz [EMAIL PROTECTED] wrote:
Whatever you do, make sure that every bit of code that locks multiple
resources locks them in the same order. That's the only way to avoid
deadlocks.
Hi Jerry,
I really appreciate the good advice.
However, my
Once you issue a LOCK TABLES command, you may not access any tables not
in the LOCK statement. You must lock *ALL* tables you will use, perform
your updates, and then UNLOCK TABLES.
I didn't know that. I reviewed the documentation. Thanks.
OK, then my only remaining question is how many
12 matches
Mail list logo
