agora inbox for postgres@postgres.berkeley.edu  
help / color / mirror / Atom feed
From: Mark Metson <gpurdy@fox.nstn.ns.ca>
To: Paul M. Aoki <aoki@postgres.Berkeley.EDU>
Cc: Michael Ubell <michael@montage.com>
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: locking [was: Use by a Business]
Date: Tue, 31 May 1994 02:55:02 +0100
Message-ID: <Pine.3.89.9405310211.B1720-0100000@acamn.aca.uucp> (raw)
In-Reply-To: <199405310253.TAA20627@faerie.CS.Berkeley.EDU>



On Mon, 30 May 1994, Paul M. Aoki wrote:

> Michael Ubell <michael@montage.com> writes:
...
> (not that the last two messages have had anything to do with what 
> the guy was asking..)
...

Ah but they do, they do. Locking is the crux of the problem. I have a 
complete application running at a Collection Agency in Business Basic 
under SCO Unix System V. Standard code developed across a number of 
employers in which when you edit a masterfile record the record is locked 
using an 'EXTRACT' until unlocked using a READ or WRITE. Meanwhile it 
sits on user's screen over lunch or until per-input timeouts realise 
they've gone to lunch. There are two pricetags, $2500 and $2300, one for 
new unix, one for new BASIC (can never recall which is which), total 
$4800, which come up every time they think about computerising another 
branch office. Assuming they have $4800 on hand, we'd all feel better if 
they spent it on something more constructive, like buying hardware or 
paying me. I wanted GNU instead of UNIX in the first place, but it wasnt 
available back then. Now, the free unix I kept telling them was on the 
horizon is here, we want to move to it. We also would like to move from 
the BASIC if it'd be cheaper to rewrite than to buy a copy per possible 
new site, and may HAVE to move from BASIC if we cannot get Business Basic 
for Linux. I have just this day discovered some ALPHA code for running 
SCO SysV executables under Linux, so possibly I might be able to stay 
with BASIC, but if not, postgres is the only thing I've seen that might 
be useable in its place, other than to take some standard ISAM code and 
write a shared-memory record-locks-table or somesuch for it; and since 
Linux kernel support for arbitrary locks has no 
deadlock-detection/protection in it, I am rather wary of potential 
deadlock situations if I try to add a key with one task while deleting a 
key with another task in the same index; I suspect record-level locks on 
the blocks ofa Btree would be in real deadlock danger in such scenarios. 
I guess Business Basic spoiled me, I had never spent much thought on what 
nifty tricks the language was taking care of for me in its 
innocent-seeming record handling system.

Blessed Be. -MarkM-


==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"

   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================



reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: gpurdy@fox.nstn.ns.ca, aoki@postgres.Berkeley.EDU, michael@montage.com
  Subject: Re: locking [was: Use by a Business]
  In-Reply-To: <Pine.3.89.9405310211.B1720-0100000@acamn.aca.uucp>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox