Lock objet failure in enhacement

Question

Hi
We have a problem with the concurrence in the legal number invoices. We realize that the lock object used works fine for the Quality environment test: different sessions; and different sessions and users.
The lock is not working on Productive environment; we could not reproduce the error, but believe that the problem is because the restrictions for the lock object.
CODE:
            CALL FUNCTION 'ENQUEUE_EZTV_SD_EXP'
              EXPORTING
                mode_ztv_sd_exp = 'E'
                mandt           = sy-mandt
                tipo_doc        = 'F'
                planta           = v_werks
                x_tipo_doc    = space
                x_planta       = space
                _scope        = 2
                _wait           = 3
              EXCEPTIONS
                foreign_lock    = 1
                system_failure  = 2
                OTHERS          = 3.
            IF sy-subrc <> 0.
  MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                      WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
            ENDIF.
            SELECT SINGLE
              FOR UPDATE
FROM ztv_sd_exp
              INTO st_ztv_sd_exp
              WHERE tipo_doc EQ 'F'
              AND   planta   EQ v_werks.
            CASE sy-subrc.
              WHEN 0.
                st_ztv_sd_exp-status = st_ztv_sd_exp-status + 1.
        UNPACK st_ztv_sd_exp-status TO st_ztv_sd_exp-status.
                MOVE: st_ztv_sd_exp-status TO st_vbrk-xblnr.
                MOVE:  st_ztv_sd_exp-status TO xvbrk-xblnr.
                MODIFY xvbrk INDEX 1 FROM st_vbrk.
                CASE sy-subrc.
                  WHEN 0.
                    MODIFY ztv_sd_exp FROM st_ztv_sd_exp.
                    CASE sy-subrc.
                      WHEN 0.
                      WHEN OTHERS.
          MESSAGE e398(00) WITH 'Imposible Actualizar Tabla'.
                    ENDCASE.
                    CALL FUNCTION 'DEQUEUE_EZTV_SD_EXP'
                      EXPORTING
                        mode_ztv_sd_exp = 'S'
                        mandt           = sy-mandt
                        tipo_doc        = 'F'
                        planta          = v_werks.
                  WHEN OTHERS.
      MESSAGE e398(00) WITH 'Imposible Actualizar Memoria'.
                ENDCASE.
              WHEN OTHERS.
           MESSAGE e398(00) WITH 'Imposible Bloquear Tabla'.
            ENDCASE.
          ENDIF.
Any help would be helpful
thanks

Answer 1

Actually I was refering to what was the error that you were seeing in production, but I'm assuming that what you're seeing is a combination of contention and the numbers getting out of sequence, so I'll give it a shot in answering.
A couple of general comments:
- You don't need to use both an enqueue object and a Select For Update.  A Select For Update does an actual explicit DB lock as opposed to an enqueue logic uses a logic lock via the application server and is a better approach.  I usually recommend the use of an enqueu object.
- Your check after the Enqueue object done checks sy-Subrc but unless a system message is raised that has a type that will cause the transaction to abort then it will continue on and attempt the update
- If you are just trying to keep an ongoing counter, I suggest using a Number Range Object.  The object can be created in transaction SNRO and then you use the function "Number_Get_Next" to get the next number in the series.  It is important though to ensure that you set up the Number Range Object according to it's purpose, for example if it is set with buffering turned on and a number higher then zero for the number of numbers to keep in memory then there is the possibility that you may end up with gaps in the assigned numbers.  If you do not set buffering turned on then there will be no gaps in the numbers assigned but only one concurent program can access at a time (the number range object is help until the transaction is commited).
With regards to what you are attempting to do, if you can not use a number range object then I would suggest staying with the enqueue object but removing the Select For Update.  The problem though that you will encounter and is most likely causing some issues is that you shouldn't be doing an explicit Dequeue prior to the transaction being commited becuase this will mean that another transaction can get the enqueue object prior to the first transaction being commited.  You need to hold onto the lock until the transaction is complete.
In the end, I would say that there are these issues with the logic in your program but my primary recomendation is that you implimnet number ranges instead of trying to reinvent the wheel on this one.
~Ian