> The reason I quoted it, though, was because I was making a
> sarcastic remark about "If you don't need transaction, then you
> probably don't need a database management system at all". Pfeh,
> tell that to my 87 tables.
let's talk OOP, shall we? ;-)
> > I infer that Greenspun is saying that atomicity cannot exist
> > outside of transaction: that without the transactional control
> > you do not have "atomic".
>
> I must admit that I'm confused on the terminology. From what
> I've reasoned out, atomicity refers to record level locking and
> transactions refer to a sequence of queries where each query
> must execute successfully or all the changes that were made are
> rolled back.
record locking is the single-instruction version of atomicity.
with a locked record, you can read it, change it, and write it
back and be confident that nobody else has done anything to it
between the read and the write.
the purpose of transaction handling is to provide the illusion
of atomicity for operations which are too complex to handle all
at one go. you can't really know the state of the transaction
until *after* you've finished processing it, but once it's over,
it either worked perfectly, or never happened. it allows you
to run make-believe scenarios on information to see whether
they'll work. if everything went as it should, you can
'commit' the transaction, which means it actually happened, or
you can roll it back, and undo any changes which occurred while
you were pretending.
the model of balancing a bank account is the traditional
example. you don't know what the final balance is until you've
added in all the deposits and subtracted out all the withdrawls.
OTOH, you can't know all the deposits are good until you've
verified each of them with the accounts they came from. you
also have to get verification and acceptance from each of the
accounts you're paying out to. it's only when you get a
complete list of all the verified transactions that you can
determine whether the account is in the red or in the black.
that decision has cascade effects, because you can't balance the
account i'm paying to until you know i have the money to cover
the check. the number of alternate scenarios is huge (what
happens if we pay this check and not that one?), and the bank
has to work out the one it likes best before it can make
definitive statements about any account.
the ability to run all the numbers and see how they work out,
then more or less say, "do over!" and try again is what transaction
handling is all about.
in networking terms, it's a way of keeping your chestnuts out of
the fire when you're doing a complex data transfer, and someone
suddenly knocks the power plug out of the computer. the one
which has just been killed is cheez-whiz, but if the machines
were communicating transactionally, nothing bad has happened to
the one at the other end.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
