Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!vrdxhq!grebyn!paisano!demasi
From: demasi@paisano.UUCP (Michael C. De Masi)
Newsgroups: comp.databases
Subject: Re: BIG, BIG fun w/Informix cursors
Message-ID: <230@paisano.UUCP>
Date: Wed, 22-Jul-87 11:13:24 EDT
Article-I.D.: paisano.230
Posted: Wed Jul 22 11:13:24 1987
Date-Received: Sat, 25-Jul-87 01:49:56 EDT
References: <229@paisano.UUCP> <1076@rtech.UUCP>
Organization: AT&T Communications.  Fairfax, VA
Lines: 93
Summary: You're right, you did misunderstand me.

In article <1076@rtech.UUCP>, jeff@rtech.UUCP (Jeff Lichtman) writes:
> From article <229@paisano.UUCP>, by demasi@paisano.UUCP (Michael C. De Masi):
> > To insure data integrity, I had put all update statements within the
> > context of a 'begin work ... commit work else rollback work' structure.
> > 
> > IMPORTANT:  Both 'commit work' and 'rollback work' have the side effect
> > of closing every active cursor in the whole damn program!
> > 
> > (FLAME ON!!!)

    ..... I complain for a while about the above activity .....

> > (FLAME OFF!!!)  Lord, do I feel better.
> > -- 
> > Michael C. De Masi - AT&T Communications (For whom I work and not speak)
> 
> Closing all cursors when committing or rolling back a transaction makes
> sense, and conforms to the ANSI SQL standard.
> 
     .....  Mr Lichtman explains his above statement nicely  .....
> 
> Now that we've established why the DBMS releases locks at commit or
> rollback time, let's consider why cursors must be closed at commit
> time.  Suppose you are in the middle of a transaction, and you have
> a cursor positioned in the middle of a table.  Now you do a "commit work".
> Suppose we want the cursor to remain open; the DBMS would still have
> to release its locks, which would mean that the cursor couldn't maintain
> whatever locks it had on its current position.  Suppose, before
> you tried to fetch the next row from the cursor, that someone destroyed
> the underlying table, or deleted the row that the cursor was going to
> advance to, or added a row in front of the one it was to advance to.
> What should happen?  Not only would it be extremely difficult to
> implement the DBMS to account for all possible cases of trying to
> use a cursor that has had the locks swept out from under it, it would
> be difficult to define what should happen in all cases (and many
> definitions would necessarily be arbitrary).
> 

Now granted, I probably don't have the level of understanding about
database theory that you do, but what about purely readonly queries that
do not cause any locking?  Granted, commiting an update does change the
nature of a given table, but can't that happen anyway?  That is, if I
do a readonly query of a group of database records, and one gets changed
by another process or user before I advance to that record, won't I get
incorrect or no longer existing data, or is there some functionality
that takes care of this of which I'm not aware?  If so, couldn't this
same fuctioanlity be used to keep readonly cursors open under the
circumstances I've described?


> It seems that Mr. De Masi got into this mess by trying to use "commit
> work" and "rollback work" to guarantee the success or failure of
> individual database statements.  That is not a correct use of transactions.
> It appears to me that Mr. De Masi is looking for statement atomicity; that is,
> he wants every individual database statement to completely succeed or
> be backed out.  This is something that every relational DBMS should provide for
> the user.  I'm not familiar enough with Informix to say whether it does
> this, but it's a pretty good bet that it does.  Therefore, there should
> be no need to test every update and either commit it or roll it back;

No, not unless you consider that one database 'transaction' from the
viewpoint of the user, may actually consist of any number of individual
database statements, any one of which is subject to failure.  This is
especially true in the case of relational databases, where the designer
is encouraged to divide logical records over any number of seperate and
distinct tables.  The actual 'update' of which I wrote in actuality
consists of at least two 'update' statements, a possible deletion and
a variable number of possible insertions which in scope spread themselves
over at least six seperate tables.  Every one of these statements must be
and is checked for error, and although you are correct, Informix does 
indeed automatically rollback statements that cause database errors,
the 'begin/commit/rollback work' structure is critical to insure that
the _entire_ transaction can be rolled back, to make the fuctionality
of the user's 'update' command truly atomic.

> It's possible that I misinterpreted Mr. De Masi's statements,

Yup!  But hey, what the hell, like you said:

> "Saints should always be judged guilty until they are proved innocent..."

                                  ;-)

Anyway, Jeff, thanks a lot for the input.  I really do appreciate
any help/explanations/arguments on this or any subject regarding
making my job easier!

Till the next disaster,
-- 
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
3702 Pender Drive, Fairfax, Virginia 22030   Phone: 703-246-9555
UUCP:   seismo!decuac!grebyn!paisano!demasi
     "Life.  Don't tell me about life." - Marvin, the paranoid android