Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!oliveb!amdahl!mat
From: mat@amdahl.UUCP
Newsgroups: comp.databases
Subject: Re: Transaction management (was Ingres vs Informix)
Message-ID: <6187@amdahl.UUCP>
Date: Mon, 13-Apr-87 18:08:51 EST
Article-I.D.: amdahl.6187
Posted: Mon Apr 13 18:08:51 1987
Date-Received: Wed, 15-Apr-87 03:23:53 EST
References: <144@mas1.UUCP> <534@cognos.uucp>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 24

In article <534@cognos.uucp>, garyp@cognos.uucp (Gary Puckering) writes:
> ...  In our QUICK product, which provides a screen-oriented
> data entry, retrieval and update facility, we allow an operator to
> change records as desired while browsing along a retrieval path.
> However, we *never* allow locks to be held across a terminal read.
> This is to prevent the problem of an operator walking away from the
> terminal and leaving records locked for long periods of time.
> 

The most interesting approach that I have seen is called "escrow locking."
The basic idea is that you "reserve" resources and hold them "in escrow."
So, if you have a transaction which is taking money out of an account,
you reserve that amount of money until you decide if the transaction
will commit or abort. Meanwhile other transactions can use the record.
If the transaction commits, then no action is required. If not, then the
money held in escrow is returned to the record. The advantage is the
transaction can take a long time without locking anything other than that
which is logically required - the amount of money in question. This
is not an ultimate solution, but obviously helpful in inventory-type
applications.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]