On 6/5/07, Brent Baisley <brenttech@stripped> 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 database.
> A good example is moving money from bank account A to B. You specify how
> much to move and that amount is debited from account A and credited to
> account B, 2 steps. If the first step happens, but not the second, then the
> first step needs to be reversed.
> Until the transaction is complete, anything querying the data needs to see
> bank account in it's state before any transaction started, a type of
> You seem to be trying implement all this manually, which you would need to
> do if you are using MyISAM based tables. But you may not need to use
> transactions at all if your data does not have real time dependencies.
I knew somebody was going to say this. Here is the relevant prose from my
One more note: I'm sure that many of the skilled users on this list will be
tempted to advocate more sophisticated methods. I appreciate all advice,
but I'm just looking for an easy way to serialize access to my database and
guarantee mutual exclusion. Each operation I want to do would take at most
half a second, so another web process waiting that long won't make a
difference. Simpler is easier for me.
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.