Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: What databases have taught me

Re: What databases have taught me

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 28 Jun 2006 17:07:07 GMT
Message-ID: <%Gyog.104041$Mn5.64417@pd7tw3no>


Aloha Kakuikanu wrote:
> Robert Martin wrote:

>> On 2006-06-23 11:10:25 -0700, "Aloha Kakuikanu"
>> <aloha.kakuikanu_at_yahoo.com> said:
>>> Order.cancel()? This is really about canceling a transaction. You have
>>> to study transaction management in order to implement this
>>> functionality correctly. Inheritance and polymorphish doesn't help
>>> here, sorry.
>> Again, this depends.  If there are several different types of customer
>> (e.g. GovernmentContractor, privateContractor, foreignContractor) you
>> might find that each of these different types must follow a different
>> procedure in order to cancel an order.

>
> To cancel a transaction you have to rollback or compensate all the
> actions -- as simple as that. Objects/classes are irrelevant.
>

The bit about rollback is usually so if the context is implementation. However, a larger context includes why the transaction is to be canceled and I think this is more important in the long run, if not to current products. Naming a method to do something called 'cancel' is nothing more than housekeeping, just as is the term 'rollback' (which is usually provided, I think, to give an illusion that one's implementation language is logically better than it really is). In terms of persistence, your use of 'compensate' makes more sense to me - either a transaction exists or it doesn't, but it can't suddenly 'un-exist', that is like saying 'no result' is a 'result'. Logically, compensation involves two transactions.

Where the RT is concerned, I've never understood the sense of rollback, it seems a desperate kind of way to get consistency, e.g., by cutting one's own legs off while attempting to remain standing. If a dbms allows the assertion of a set of facts upon which a successful transaction is predicated, either all of them are true or not. If even one assertion is determined to be not true, as far as the database and its constraints are concerned, then there ought to be no persistent transaction in the first place (by persistent I don't just mean some write to disk, 'side-effects' such as messages might well be considered part of a transaction and the assertions might well be transient). At implementation time, surely all the code needs to do is decide whether all the assertions some human has arbitrarily decided constitute the transaction are true. I agree that doing this is complicated when the host language involves statement ordering and assignment, as long as one chooses such languages, I couldn't criticize an impl'n that copped out by allowing 'rollback'.

p Received on Wed Jun 28 2006 - 12:07:07 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US