what for release statement inside the transaction block?

[nabesa]

Hi Everybody,
many times on this forum i've found the construction like this:

DEF BUFFER b-cust for customer.

FOR EACH customer NO-LOCK:

FIND FIRST b-cust EXCLUSIVE-LOCK
WHERE ROW-ID(b-cust) = ROW-ID(customer).

b-cust.xyz = 'xyz'.

RELEASE b-cust.

END. /* for each customer */

My question is, what for Release statement after the buffer b-cust is updated? Why it is advisable by some Forum Speakers to put Release Statement after buffer b-cust is updated inside the transaction block? What would happen if i tried not to put Release statement after updating b-cust in this case? Doesn't transaction block for each.... make realease of b-cust automatically after the one for each iteration is done? Does it make sense to release one record inside the transaction since it cannot be released till the transaction is not finished? As far as im concerned Release makes the Trigger fires. But the Trigger would fire at the end of the record scope (and in this case at the end of the transaction scope) default by Progress. Wouldn't it?

Thanks in advance for any help.

 

[StuartT]

Hi Everybody,
many times on this forum i've found the construction like this:

DEF BUFFER b-cust for customer.

FOR EACH customer NO-LOCK:

FIND FIRST b-cust EXCLUSIVE-LOCK
WHERE ROW-ID(b-cust) = ROW-ID(customer).

b-cust.xyz = 'xyz'.

RELEASE b-cust.

END. /* for each customer */

My question is, what for Release statement after the buffer b-cust is updated? Why it is advisable by some Forum Speakers to put Release Statement after buffer b-cust is updated inside the transaction block? What would happen if i tried not to put Release statement after updating b-cust in this case? Doesn't transaction block for each.... make realease of b-cust automatically after the one for each iteration is done? Does it make sense to release one record inside the transaction since it cannot be released till the transaction is not finished? As far as im concerned Release makes the Trigger fires. But the Trigger would fire at the end of the record scope (and in this case at the end of the transaction scope) default by Progress. Wouldn't it?

Thanks in advance for any help.

The code would be more like:
DEF BUFFER b-cust for customer.

FOR EACH customer NO-LOCK:

DO TRANSACTION:
FIND FIRST b-cust EXCLUSIVE-LOCK
WHERE ROW-ID(b-cust) = ROW-ID(customer).

b-cust.xyz = 'xyz'.

RELEASE b-cust.
END. /* Transaction */
END. /* for each customer */

 

[nabesa]

Thanks You StuartT
but what for Release Statement?

 

[shireeshn]

hi nabesa,
maily transaction means we are going to update the some thing. so the record will be in exclusive-lock or shared lock.

After transaction the record should in "no-lock" or release (no pointer to record) becouse we are not going to update any thing.

we go for no-lock when we want the pointer on the record after the transaction.
we go for release when no more require ponter to the record after the transaction.

if we dont use them the record will go for shared lock, which i not advisiable. so we go for no-lock or release.

 

[StuartT]

The reason for the Release statement is to ensure that the lock is released properly. Progress SHOULD release locks on finishing the transaction but sometimes it doesn't. It is more a case of just being safe.

 

[shireeshn]

hi StuartT,

i Think progress do things as they defined, it does not behave differently, we have some process how to down grade the locks.

if iam wrong put forword the points, i will calrify.

 

[nabesa]

Hello StuartT, Hello Shireeshn,
i understand and agree with Your suggestions that it is advisable to downgrage the share-lock to no-lock on the record after the transaction is ended. I know it makes sense when the record scope is bigger than the transaction scope.
But is it really advisable to put the RELEASE statement on finishing the transaction in the case when record scope and transaction scope is the same?

 

[TomBascom]

Personally I never use RELEASE. I'm always suspicious of code which does use it because it is rarely doing what the author expects it to do. In particular it does not release locks as described above.

ID: P122120
Title: "When does the RELEASE statement commit a record to the database?"
Created: 02/07/2007 Last Modified: 09/05/2007
Status: Unverified


Goals:
# When does the RELEASE statement commit a record to the database?
# When does the RELEASE statement not commit a record to the database?
# How the RELEASE statement affects locks?
# Does the RELEASE statement release locks?


Fixes:
The RELEASE statement is intended to release a buffer, not the locks on records contained in them.

Depending on the state of the buffer, release can have several side effects, including changes in the lock status:

1.) If a record in a buffer has been updated, or if the buffer contains a newly created record and the record has not yet been written to the database, it will get sent to the server where it will be written to the database.
Note that the database block containing the record (or blocks if the record is fragmented) will be updated, but the block is not written to disk at this point. Index entries will also be created or updated if needed.

2.) If there is a lock on the record in a buffer, and you are in a transaction, the lock cannot be dropped yet.
The server will be notified so it will know to release the lock at the end of the transaction.
The lock becomes a "limbo" lock at this point.

3.) If there is a (share) lock on the record in the buffer, and you are not in a transaction, the lock will be dropped

4.) Finally, the buffer contents are discarded after any of the relevant situations above have been taken care of.

 

[tamhas]

The bottom line here is that if you tightly scope your transaction and buffer scope like you should, release has no function.

 

[KrisM]

Fact is that when you have procedures that are run persistently and stay in memory for a long time, release makes a lot of sense.
I have solved many bugs with adding an explicit release statement anyway. :awink:

 

[TomBascom]

IMHO that tells me that you probably suffer from record and transaction scoping issues. Probably in the form of "borrowed buffers".

 

[tamhas]

I second Tom's remarks. The persistence of the procedure is irrelevant. Compile your programs with the LISTING option and check transaction and record scopes. Use the TRANSACTION keyword and FOR buffer on blocks to explicitly scope. Use named buffers rather than default ones to make it very clear. Do that, and you will never need RELEASE and you will cut out a lot of potential lock contention issues as well.

 

[enoon]

Well, once a fatal progress "crash bug" (some C++ type) has been solved by putting a RELEASE. You wouln't believe where: in a for each for a temp-table record in CHUI. So sometimes, it may have a logic to use it in the above mentioned construction.

 

[TomBascom]

Allegedly solving an obscure bug once upon a time does not qualify as a best practice. More like Voodoo.

 

[Cringer]

So is there ever a case for using RELEASE or should we petition Progress to remove it from the language?

 

[TomBascom]

As much as I might like them to, it is unlikely that they would ever remove it.

OTOH you could just add it to the keyword forget list (the -k startup parameter). That's almost as good

My current -k list:

CAN-DO
USE-INDEX
RELEASE
FIRST
LAST
SELECT
EDITING
CHOOSE

(ok, that's only a partial list...)

 

[tamhas]

That you solved the problem using RELEASE doesn't mean that RELEASE was the right way to solve the problem. Chances are that correct scoping would also have solved the problem.

 

[tamhas]

Removing it would cause a lot of disruption because of all those people who have used it in their code without understanding what it did and didn't do.

 

[Cringer]

Removing it would cause a lot of disruption because of all those people who have used it in their code without understanding what it did and didn't do.

Would be fun to watch though

 

[Cringer]

As much as I might like them to, it is unlikely that they would ever remove it.

OTOH you could just add it to the keyword forget list (the -k startup parameter). That's almost as good

My current -k list:

CAN-DO
USE-INDEX
RELEASE
FIRST
LAST
SELECT
EDITING
CHOOSE

(ok, that's only a partial list...)

Genius! I shall investigate.