l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Apr 24 19:24

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Unnecessary RDBMS features [was Need your help in recovering database.]

On Thu, Apr 24, 2003 at 01:48:04PM -0700, Tim Riley wrote:
> Commit/rollback requires that a copy be made of each datum involved
> in an insert, update, or delete statement. This is very expensive. But
> why make the copy? I know my insert, update, or delete is the correct
> thing to do at the time.

But what about the quite frequent case where what you're doing is the
correct thing to do *only* if the next transaction you're about to do

There are many cases where it would be a bad thing to let the
transaction you just completed remain effective if the next one
fails. If the server shuts down right between the two, you are left
with quirky data.

Example: suppose you need to insert a customer's order for a set of items in
your e-commerce solution. Your solution is to add a row to the Order
table, plus one row in the Ordered_Items table for each item ordered
(so Shipping can determine what to ship). You link the two by ID in
another table, so you can find the Ordered_Items by the Order, and

If either the web server or database server goes down while you're
adding Order_Items, you'll have an incomplete order, with no way of
knowing that it is incomplete. This is Bad(TM).

To make matters worse, there's the following chicken-or-egg problem:
You want to charge the customer's credit card for the order, but not
unless you're sure that the order will be in the database - customers
get very irate when charged for a service they have not
received. OTOH, it'd be just as bad to put the order in there, then
charge the customer, only to find out the credit card info is bad, and
then be unable to delete the order because, right at that very moment,
the web server crashed, and you have no contextual information to tell
you later that that order shouldn't be in there because you haven't
been paid for it yet. The only way I know of to resolve the situation

  1. Create the order in the DB.
  2. Attempt to charge the card.
  3. If the charge was successful, commit the Order and all the
  4. If the charge was unsuccessful, rollback.

> If I'm making a mistake to the database,
> I'll fix it when I catch it.

You must be server-psychic. Can you explain to me how you would catch
the errors above, in a reliable fassion?

> > I
> > agree with you that feature creep causes major bloat, which in turn
> > causes huge opportunities for bloat.
> If you want to expand on this more, there are other areas of Oracle-like
> DBMS features that cause unnecessary bloating and headaches.

Unnecessary is a relative term.

> > But when you have such an
> > important feature for guaranteeing data reliability,
> I'm curious to learn what you consider data reliability to be
> and how commit/rollback guarantees it.

See above example. In my experience, commit/rollback is worth its
weight in gold*


*Of course, if you took that statement /literally/, you'd probably
 agree with me, since it doesn't way anything... ;)
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.