transaction

This sounds awfully like an exam question. Have you done any research yourself? Where have you looked? What have you found out?

---

[collapse] From: balaji [mailto:bounce-balaji@community.progress.com]
Sent: Monday, April 14, 2014 1:57 AM
To: TU.OE.General@community.progress.com
Subject: transaction

transaction

Thread created by balaji

.After the transaction is complete exclusive lock downgrades to which lock?

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Release does not do what you think it does. Refinding with a no-lock also does not do what you think it does.

The key, here, is to scope the buffer the same as the transaction and then it is a non-issue.  Everything else is self-deception.

---

[collapse] From: James Palmer [mailto:bounce-jdpjamesp@community.progress.com]
Sent: Monday, April 14, 2014 9:38 AM
To: TU.OE.General@community.progress.com
Subject: RE: transaction

RE: transaction

Reply by James Palmer

Release does not do what you think it does. Refinding with a no-lock also does not do what you think it does.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

As Thomas says, you need to scope your buffers correctly, and not fudge the locking. You will find you introduce bugs to the system that are hard to track down by using release and refind of records no-lock. If you explicitly find your records exclusive-lock within the scope of the transaction itself then there is no need to release as the locks will be released at the end of the transaction block. If you find yourself having to add release statements then your scoping is wrong. You will find you have unexpected behaviour when transactions roll back, and you may well find you get lock table overflows.

[collapse]

RE: transaction

Reply by James Palmer

Release does not do what you think it does. Refinding with a no-lock also does not do what you think it does.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Flag this post as spam/abuse.

Click here to report this email as spam.

Inenco group Ltd Petros House, St Andrews Road North, Lytham St Annes, Lancashire, FY8 2NF Company Reg No: 2435678 For further information on the Inenco Group Ltd please visit our web site at www.inenco.com

NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Inenco Group Ltd. and the recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Whilst this e-mail or attached documents may contain market information, this information is not provided as advice. Inenco do not accept any liability for any damages or losses of any kind suffered as a result of any action(s) taken as a result of the content of this e-mail or attachments. Any views or opinions presented are solely those of the author and do not necessarily represent those of Inenco Group Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. If you have received this email in error please notify the sender by telephone on +44 (0)1253 785000. [/collapse][/collapse]

Steph, if you add for table to the do transaction, then you don't need to do any of the stuff afterwards.  Better yet, put these actions in an IP or method, define a buffer in that IP or method, and the buffer use will be scoped to the IP or method.  The first time you add in this kind of scoping, you are likely to get complaints from other places in the code and need to add it there.  But, if you do this consistently, there is no ambiguity about locks and no possibility of mysterious interactions.

While having the tx and the buffers have the same scope is "safer", there is nothing wrong with raising the lock for an existing buffer, changing the data, and then issuing a "request" to lower the lock level on that buffer when the TX ends.

Steph - the problem about FIND CURRENT NO-LOCK and RELEASE that has been alluded to earlier is that notion that doing a FCNL or REL will downgrade the lock immediately. These statements do not change the current locking level until such time as the TX ends.

Finally, assertions that using FCNL and REL will cause "other problems" are unsupported fear-mongering. If they're used properly - which you appear to be doing - then they're perfectly fine as a programming practice.

From the OE ABL Essentials:

"If you have any doubt at all about when a record goes out of scope or when a lock is

released, release the record explicitly when you are done updating it with the RELEASE

statement."

I recommend you read "Handling Data and Locking Records", understand locking the best you can.  Read it several times, create examples and take notes on the behavior.  Do not fall into fear mongering.

Steph, sticking in a few FOR TABLE additions to control scope does not require rewriting the application, but does accomplish what a lot of fiddling with finds and releases does not.  I have never seen a situation where I couldn't control scope to the benefit of the clarity of the program.

@steph:

the RELEASE statement is not for releasing locks. it is for releasing /buffers/. it causes the specified buffer to be cleared so that it contains nothing. if necessary, its contents will first be sent to the database (e.g. if a new row was created or a row was updated) and then it will be cleared, which has the effect of ending its scope even though its lexical scope may be longer.

this clearing of the buffer also has the effect of ending or reducing the "lock scope".

if the buffer contains a row with a lock and it is released inside a transaction, then the buffer will be cleared but the row lock will not be released /until the transaction ends/.

if the buffer contains a row with a share lock and it is released outside a transaction, then the row lock will be released when the buffer is cleared.

if the buffer contains a row with a NO-LOCK then there is no lock to release when the buffer is cleared and inside or outside a transaction makes no difference.

note that after you release a buffer, you can read something else into it (or even the same thing).