Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!wdl1!mas1!gupta
From: gupta@mas1.UUCP
Newsgroups: comp.databases
Subject: Transaction management (was Ingres vs Informix)
Message-ID: <144@mas1.UUCP>
Date: Thu, 2-Apr-87 15:29:28 EST
Article-I.D.: mas1.144
Posted: Thu Apr  2 15:29:28 1987
Date-Received: Sun, 5-Apr-87 06:41:31 EST
Lines: 63

In article <477@cognos.UUCP> garyp@cognos.UUCP (Gary Puckering) writes:
>  
> The scenario you describe points out that their are two types of 
> transactions:  read_only and read_write.  A transaction involving only
> queries (i.e. only SELECT's) can be read_only.  This enables the database
> manager to perform a Versioned Read on the tables involved...

The primary reason why a lot of systems do not provide this to the user is that
the user would then have to specify that they were doing a read-only
transaction at the start of the transaction.  I agree that this is not a very
strong argument, and that versioned reads should be provided.

> ...
> An objection I have to many relational systems is the lack of choice
> they provide in transaction control.  I can understand why degree 3
> consistency is the default, but I can't understand why some systems
> don't allow you the option of degree 2 or even degree 1...

I agree that the system should provide the capability.  I guess that the
reason for not providing this ability is that they are afraid of the user
using the features incorrectly and then complaining that it is the DBMS's
fault.

> ...
> While on the subject of transactions, has anyone encountered problems
> with the fact that most relational database managers cannot retain
> your cursor position once you've committed the transaction?  If so,
> in what circumstances have you encountered the problem and how did
> you get around it?

As a DBMS implementor, I would like to ask the question:

    What are the semantics of a cursor, once the transaction is committed?
	OR, put differently,
    What are the semantics of transactions if cursor stability is provided
    accross transaction boundaries?

To explain, here is a scenario:

    User starts read-only transaction.
       Opens and positions the cursor.
    Commits the transaction.
	...
    Starts read/write transaction.
       Is the previous cursor still valid?

Here is another:

    User does read/write transaction.
       Opens and positions the cursor.
       ...
    Commits the transaction.
	...
    User starts another transaction.
       Is the previous cursor still valid?

The main problem is that between transactions the state of the database may
change, thus the cursor may no longer be valid.

-- 
Yogesh Gupta				{ ihnp4!mas1!gupta }
Measurex Automation Systems		           ^
						This is a "one"