1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Question Deadlock

Discussion in 'Development' started by Kalan, Apr 3, 2017.

  1. Kalan

    Kalan Member

    Two different procedures are deadlocking each other by accessing the same record from two different sessions. Not sure if any other workaround to deal this type of scenario.
    Could someone pls suggest on this? - Thanks.

    For example,
    Proc-1.p
    Do Transaction:
    Access the record with exclusive-lock no-wait.
    If locked then
    Repeat while locked <rec>:
    Access the record with exclusive-lock no-wait.
    End.
    if avail <rec> then
    update <rec>.
    End transaction.

    Proc-2.p
    Do Transaction:
    Access the record with exclusive-lock no-wait.
    If locked then
    Repeat while locked <rec>:
    Access the record with exclusive-lock no-wait.
    End.
    if avail <rec> then
    update <rec>.
    End transaction.
     
  2.  
  3. TomBascom

    TomBascom Curmudgeon

    Strictly speaking that is not a "deadlock" Deadlock - Wikipedia since one session is actually working with the record.

    Presuming that the issue is something along the lines of "update takes a long time so session 2 has to wait" then what you are doing is (more or less) the proper solution.

    Although you should take a nap between retries so that you don't beat the crap out of the poor computer.

    Alternatively you could omit NO-WAIT and just queue for the lock to be released.

    You should also be performing the transaction with a strong-scoped buffer. IOW:

    Code (progress):
    1.  
    2. do for BUFFERNAME transaction:
    3.   find BUFFERNAME ...
    4.   assign
    5.     /* stuff ... */
    6.   .
    7. end.
    8.  
    If the "update" is an actual UPDATE statement rather than pseudo code then you are committing a grievous sin -- you have user-interface activity at the same time as a record lock and a transaction are active. That means that the user can get a cup of coffee, go to lunch or head to the beach for a nice long vacation -- and everyone will have to wait for that user to return... (or for the -lkwtmo timer to expire). True, lots of old, horrid code behave like this. But there is no reason to keep repeating the crimes of the past.
     
  4. Kalan

    Kalan Member

    Thanks Tom, My apologies, its pseudo code and not exact 'update' statement. I agree that it's not deadlock and my understanding is that they have written this code segment to avoid deadlock scenario and enforcing control using repeat loop to obtain the record on exclusive-lock mode. If session-2 process transaction scope is taking such long time to complete then session-1 process keep checking record status using repeat loop and gives the impression to user that "session freezing/hanging".
     
  5. TomBascom

    TomBascom Curmudgeon

    Why is the process taking a long time?

    That seems like something I would want to address as a priority.
     
  6. tamhas

    tamhas ProgressTalk.com Sponsor

    Right, one of the principles of good ABL programming is to figure out what needs changing without opening a database transaction and then to open, apply, and close in the shortest possible time. If you do that, then the problem goes away.
     
  7. RealHeavyDude

    RealHeavyDude Well-Known Member

    I can only second that. Not designing your code for transactions that are acitve for an as short as possible duration is a recipe for all sorts of problems. Not only might users be blocked from work, you might even hurt your database.

    Heavy Regards, RealHeavyDude.
     

Share This Page