Locks in Progress 10.2B

[nandanak]

How progress locking mechanism behave in following code (Progress 10.2B) ?

DO:
Find First TABLE1 NO-ERROR.
IF AVAILABLE TABLE1
DO:
some TABLE1 updation codes here.....
END.
END.

1. Because lock is not mentioned, Is default lock SHARE-LOCK ?

2. Is SHARE-LOCK converts to EXCLUSIVE-LOCK when table update ? Then where Exculisive lock is realaesed
(After outer DO block or inner DO block) ?

 

[Cringer]

You should always define what sort of lock you want. Share Locks are the road to insanity IMO. You should also strongly and tightly scope any transactions so you don't hold onto locks longer than you need.

AFAIK the code above will have an exclusive lock on the record within the scope of the transaction block (ie where the updates occur) and then when it drops out of that block it will downgrade to a share lock. I could be a bit wrong as I've not really studied what happens in terrible code like that!!

 

[RealHeavyDude]

SHARE-LOCK is the default lock if you don't explicitly specify neither NO-LOCK nor EXCLUSIVE-LOCK. To me it is a leftover from stone age IT where the thought of users accessing your database concurrently was beyond real life.

Not specifying the lock or using SHARE-LOCK is worst practice. It is the road to hell. There is hardly a use case which justifies the usage of it. In all of my Progress developer's life I was only able to come with one valid use case in which I deliberately use a SHARE-LOCK to synchronize threads. Therefore, never use SHARE-LOCK unless you are absolutely sure about what you are doing and have a valid use case. Plus, not specifying the lock hardly makes your code transparent.

Regarding your question: At the end of the transaction scope, if the buffer scope is larger than the transaction scope, the EXCLUSIVE-LOCK will be downgraded to a SHARE-LOCK. If they are equal the EXCLUSIVE-LOCK will be released at the end of the transaction scope. You code probably has another issue: The transactions scope is extended beyond the DO block which encloses the FIND - simply because DO blocks do not have scoping capabilities unless you explicitly specify them. In such a case the transaction and buffer scopes are extended to the next outer block with scoping capabilities - which might be the whole procedure. You should make yourself familiar with the concepts of buffer and transaction scope - it is essential knowledge for making good code that updates the database.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

The unnecessary use of FIRST is also a worst practice. If you have a UNIQUE find then the "first" is pointless. If you do not have a unique find then "first" is creating a "magic record" and breaking 3rd normal form (unless you are initiating a loop which will process all records using NEXT).

 

[TomBascom]

A better way to code an update:

do for table1 transaction:

  find table1 exclusive-lock where table1.something = someValue no-error.

  if available( table1 ) then
    do:
      assign
        table1.whatever = updatedData
      .
    end.
   else
    do:
      /* handle the problem */
    end.
end.

The "do for" strong scopes the table1 record buffer -- you will get compile warnings if there are other references to table1 scoped wider. Resolving those will require an understanding of record scope. Or you can use a named buffer for the update.

 

[tamhas]

To reinforce a point, one of the issues in your code is that DO does not provide transaction or buffer scope unless you use the FOR table version. Thus, one can't really tell you what the transaction or buffer scope is in your original code fragment since there is nothing in that fragment which defines scope.

 

[Stefan]

SHARE-LOCK is the default lock if you don't explicitly specify neither NO-LOCK nor EXCLUSIVE-LOCK.

Unless you compile with a session started with the -NL startup parameter, in which case all queries without a lock specified are NO-LOCK instead of SHARE-LOCK.

But yes, also a +1 for always specifying the lock type (and never shared), tight transaction and buffer scoping.