Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!infmx!aland
From: aland@infmx.UUCP (Dr. Scump)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Summary: page mode lock contention
Keywords: Client Server Processes
Message-ID: <2813@infmx.UUCP>
Date: 10 Dec 89 21:48:32 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> <=LD.=$#@unify.uucp>
Reply-To: aland@infmx.UUCP (alan denney)
Organization: INFORMIX Professional Services ("Peace thru Normalization")
Lines: 23

In article <=LD.=$#@unify.uucp> jwc@unify.UUCP (J. William Claypool) writes:
>In article <2762@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>>(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 >jwc@unify.UUCP  

You mean, you would recommend the use of page mode locking in such 
an application (constant history table inserts) ???

--
    Alan S. Denney  @  Informix Software, Inc.    
         {pyramid|uunet}!infmx!aland                 "I want to live!
   --------------------------------------------       as an honest man,
    Disclaimer:  These opinions are mine alone.       to get all I deserve
    If I am caught or killed, the secretary           and to give all I can."
    will disavow any knowledge of my actions.             - S. Vega