How to deal with Advantage Proprietary Locking and DbServer.ConcurrencyControl

This forum is meant for questions and discussions about the X# language and tools
Post Reply
hilberg.it
Posts: 75
Joined: Sun Sep 20, 2020 7:25 am
Location: Germany

How to deal with Advantage Proprietary Locking and DbServer.ConcurrencyControl

Post by hilberg.it »

Hi,
thanks already for all your helpful comments! I have another issue about migration from DBF to ADS. How should I deal with concurrency control from DbServer? I want to use Advantage Proprietary Locking. In my DBF code there are a lot of calls to

Code: Select all

self:concurrencyControl := CCNONE
or

Code: Select all

self:RLOCK (nRecno) .... self::Unlock()
I want to use ADS to manage locking like stated in the docs:
The Advantage Database Server uses an intelligent lock management system with its proprietary locking mode that eliminates lock retries and requires no network traffic. The Advantage Database Server uses an internal queuing algorithm that allows application locks to occur without making network operating system lock API calls. All locking information is maintained internally in the lock queues.
Does that mean that I should get rid of all the lock/unlock calls in my code? How should I configure DbServer:concurrencyControl? Or will ADS simply ignore my API calls?
Thanks.
ic2
Posts: 1858
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

How to deal with Advantage Proprietary Locking and DbServer.ConcurrencyControl

Post by ic2 »

Hello,
hilberg.it wrote: Does that mean that I should get rid of all the lock/unlock calls in my code? How should I configure DbServer:concurrencyControl? Or will ADS simply ignore my API calls?
If I interpret that line of ADS documentation, it looks like t it just says that it "eliminates lock retries". That is a bit confusing.

We are using ADS in all our applications and an explicit lock isn't required indeed as we do not lock anything.
However, I can tell you that when writing to a DBF is finished and no Commit()+Unlock() takes place changes are often not visible when directly opening the DBF in another instance and looking for the change. If changes take place in a loop we only issue these commands after the loop is finished as it will take time to execute.

Furthermore, we use CC_OPTIMISTIC. WIthin table views, where a user can not modify the data, we add

Code: Select all

SELF:Server:ConcurrencyControl:=CCNONE
which is reset to CC_OPTIMISTIC as CCNONE speeds up the tableview considerably.

That is what I can say about it from our experience.

Dick
g.bunzel@domonet.de
Posts: 97
Joined: Tue Mar 01, 2016 11:50 am
Location: Germany

How to deal with Advantage Proprietary Locking and DbServer.ConcurrencyControl

Post by g.bunzel@domonet.de »

Hello,

we also work with ADS since many years and
self:concurrencyControl := CCNONE.

Do not change that. We have also this in our code:
self:RLOCK (nRecno) or self:FLOCK ()
...
self::Commit()
self::Unlock()

Works perfect without problems. With that code your can switch between ADS and DBFCDX with only changing the RDD.

Gerhard
Post Reply