<color><param>0100,0100,0100</param>On 5 Feb 99, at 13:59, Jack Killpatrick wrote:
<color><param>0000,0000,0000</param>> Yeah, actually I quoted that in an earlier part
of this thread. The reason
</color>Eeeks. I must have missed that.
<color><param>0000,0000,0000</param>> 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.
</color>I much prefer using a rdbms to my old methods of dbm and ascii files.
I imagine using perl DBD helps a lot and I have abstracted a bit
further to make it even easier to use (at least for me).
<color><param>0000,0000,0000</param>> So perhaps atomicity is really just a term to
define the elements of the
> transaction and not to refer to record-level locking (although
> record-level locking may be a part of the transaction funtion)? This
> definition would not quite make sense when compared to the way Monty as
> MySQL used it:
</color>I have been searching for this. So far the best I have found was
this:
<color><param>0000,0000,0000</param>> the relational principle of atomicity,
> which has it that all operations are executed completely or not at
> all.
</color>from here:
<color><param>0000,0000,0000</param>http://www.bby.com.au/~crn/Ingres-FAQ.txt
</color>Imagine this:
<color><param>0000,0000,0000</param>> UPDATE CUSTOMER
> SET REP# = 4
> WHERE REP# IN (2,3)
which is part of a good, simple slide definition of a relational
database:
</color>http://www.luc.edu/faculty/mmallia/492/powerpoint/night4/tsld001.htm<color><param>0000,0000,0000</param>
</color>You will be changing from 0 to X number of records. Atomicity would
require that you either change (0 to X) or change nothing.
As we get into ecommerce the answers to these questions will be
paramount.
I wrote once wrote database application where I actually wrote my own
rollback. I had a field in each table whose sole purpose was simply
to relate it with other entries that were changed at the same time.
I created the unique number for that field and then did an eval on
the operations and if it failed for any reason then I would delete
every row in every table that had that unique number. But ... but ...
what if the program itself failed halfway through the changes ...
then my rollback would not work.
It is said that the database will know this (I really wonder how).
What if the electricity is pulled halfway through an operation? ...
Ummm... if the database saves proposed changes to disk and then must
delete those changes once a committ is made .... and when you restart
it the database notices that no committ was executed for those
proposed changes and so it will then "rollback" that which was
done...
It seems to me that using something like MySQL will at least
eliminate all the flocking that I always hoped work, but I don't
think it will support MULTIPLE operations with absolute certainty. I
will post my questions to the mysql list and see what they say.
Peter
<nofill>
____________________________________________________________________
--------------------------------------------------------------------
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
---------------------------------------------------------------------
