Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!tut.cis.ohio-state.edu!ucbvax!ucdavis!csusac!unify!jwc
From: jwc@unify.uucp (J. William Claypool)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <=LD.=$#@unify.uucp>
Date: 5 Dec 89 22:23:39 GMT
References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> <936@anasaz.UUCP> <2762@infmx.UUCP>
Reply-To: jwc@unify.UUCP (J. William Claypool)
Organization: Unify Corporation, Sacramento, CA, USA
Lines: 16

In article <2762@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>This depends on in what way the processes are "active".  If they are
>competing for update access to exactly the same pages, lock contention
>can indeed make the database spend much of its time managing locks.
>(For example, running multiple insert processes against the same table
>with page mode locking in use is considered to be in poor taste :-]).
>In a normal transaction mix, however, these lock contentions are
>atypical.

Unless, for example, you have an application where every transaction
does an insert into a history table.  ;-)
-- 

Bill Claypool    W. (916) 920-9092 |I know what I know if you know what I mean
jwc@unify.UUCP   H. (916) 381-4205 |------------------------------------------
    ...!{csusac,pyramid}!unify!jwc |  SCCA SFR Solo II   74 es  1984 CRX 1.5