Re: A question about record locks

[Pete Helgren <Pete@xxxxxxxxxx>]

So it seems like Chris' approach, or something similar, will always be 
the safest bet since the time between chain and update will always be 
minimized (nearly eliminated).  The user who retrieves a record for 
maintenance and wanders off somewhere, won't prevent a process from 
proceeding by locking a record.

The posting routine may delete records, so I'll need to take that into 
account, as well as an update that changes the record from another source.

This will take some time to change the program but seems the best all 
around approach.  I'll dig into the archives for examples. 

Thanks.

Pete


Wilt, Charles wrote:
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx 
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
> > Sent: Tuesday, October 24, 2006 12:58 PM
> > To: Midrange Systems Technical Discussion
> > Subject: Re: A question about record locks
> >
> > Chris, Simon, Wilt,
> >
> > If program 1 issues a CHAIN(N) on the record then it cannot issue an 
> > update immediately after?  
> >     
>
> Correct.
>
>   
> > I understand that using a chain(N) 
> > and then 
> > an update is dangerous, someone else could have updated the 
> > record, but 
> > are you saying a chain(n) and then update would fail because 
> > it cannot 
> > be done?  
> >     
>
> Yes, before you can update the record, it has to be read and locked via
> a CHAIN/READ/READE/READP/READPE without the (N) extender.
>
> You can't update a record you don't have locked.
>
>   
> > I'll have to go back at look at the code, seems to 
> > me it does 
> > do a chain(n) and then an update but as Wilt said, maybe I missed 
> > another chain somewhere.
> >
> > How about SQL ?  If embedded SQL was used to read through the 
> > records in 
> > the posting program B, when someone was maintaining a record 
> > in program 
> > A, would the SQL fetch fail for the same reason?
> >     
>
> Yep.  SQL isn't magic.  It can't do anything RPG can't do.  It works
> through the DBMS same as RPG native I/O.
>
> SQL0913 - Row or object &1 in &2 type *&3 in use.
> If a record is locked by another application process, try the SQL
> statement again when the record is not in use. The Display Record Locks
> (DSPRCDLCK) command will determine who is currently using the record.
>
>   
> > Thanks for the information.  I'll have to review the code and ponder 
> > this a bit more.
> >
> > Pete
> >
> >     
>
> Charles Wilt
> --
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
>  
>
>