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