record scope and lock question

[ruan007]

Hi,

To my understanding, if a record is being updated with an exclusive-lock, the record lock will not be released until either the transaction or the record buffer is out of scope the last.

Looking at the following two listing files, both customer buffers are scoped to the entire procedure. After the "waiting" message poped up, I ran another prowin32 session and tried to update the same customer, only testing2.p still had the record being locked. In testing.p, the lock was released after the internal procedure finished.

This is confusing me, can anyone clarify please?

Thanks

c:\temp\testing.p 08/08/2011 16:35:12 PROGRESS(R) Page 1
{} Line Blk
-- ---- ---
1 RUN updcust.
2 MESSAGE "Waiting...." VIEW-AS ALERT-BOX.
3
4 PROCEDURE updcust:
5 FIND customer WHERE custnum = 1 EXCLUSIVE-LOCK.
6 customer.comments = "testing".
7 END.
c:\temp\testing.p 08/08/2011 16:35:12 PROGRESS(R) Page 2
File Name Line Blk. Type Tran Blk. Label
-------------------- ---- ----------- ---- --------------------------------
c:\temp\testing.p 4 Procedure Yes Procedure updcust
c:\temp\testing.p 0 Procedure No
Buffers: sports2000.Customer


c:\temp\testing2.p 08/08/2011 16:45:10 PROGRESS(R) Page 1
{} Line Blk
-- ---- ---
1 1 DO TRANSACTION:
2 1 FIND customer WHERE custnum = 1 EXCLUSIVE-LOCK.
3 1 customer.comments = "testing".
4 END.
5
6 MESSAGE "Waiting...." VIEW-AS ALERT-BOX.
7
8
c:\temp\testing2.p 08/08/2011 16:45:10 PROGRESS(R) Page 2
File Name Line Blk. Type Tran Blk. Label
-------------------- ---- ----------- ---- --------------------------------
c:\temp\testing2.p 0 Procedure No
Buffers: sports2000.Customer
c:\temp\testing2.p 1 Do Yes

 

[RealHeavyDude]

A DO block without an explicit strong scoping ( DO FOR customer, for example ) does not have buffer scoping capabilities. Therefore, in your testing2.p the customer buffer is scoped to the next outer block which is the procedure itself. As the buffer scope is larger than the transaction scope, at the end of the transaction scope the exclusive-lock on the customer is downgraded to a SHARE-LOCK. That's is expected behavior.

In order to avoid you scoping issues in the first place, IMHO of course, you should always use defined buffers and strong scoping when updating the database to make sure that the transaction scope matches the buffer scope or the transaction scope is lager than the buffer scope.

Heavy Regards, RealHeavyDude.

 

[ruan007]

Thanks for the reply. I understand the behavior for testing2.p, what confused me is why testing.p didn't behave the same, as the buffer is also scoped to the next outer block, which is the entire procedure.

Regards

 

[RealHeavyDude]

That is because the buffer is referenced in an internal procedure of the procedure. An internal procedure block does have buffer scoping capabilities - and it is the next outer block, therefore the buffer is scoped to the internal procedure and not the procedure itself.

Heavy Regards, RealHeavyDude.

 

[ruan007]

The listing file shows the "Line Blk" being 0, that I think it's the procedure itself, if i explicitly define the buffer inside the IP, i am sure the listing file will shows the "line Blk" being 4. Is this a mistake by PSC?

Regards

 

[RealHeavyDude]

I think you are right that the compiler listing does not correspond with our findings. As I have no OE development environment at my disposal right now I can't double check - but I have never experienced a bug with the compiler listing.

Heavy Regards, RealHeavyDude.