Interface Locked by user

[Former Member]

Hello,

We have batch job in which same interface is called with different variants.

The job is failing with an error for some variants.

The error is ' <b>Interface Locked by user</b> '

What could be the reason for this?

Kindly help.

Thank u in advance.

Pranali

[naimesh_patel]

May be you are trying to change the SAME interface back-to-back.

Use some Wait option like, between your call transactions.

<b>WAIT UP TO 100 SECONDS.</b>

Regards,

Naimesh Patel

[Former Member]

hie...

the batch job is executed every day...but every time it fails for some differrent differrent variants. and sometimes it does not fail at all.

what could be the reason.?

Regards

Pranali

[Former Member]

Might be in the interface you are checking for multiple instances running,

go through the code and see where it is coming from

[Former Member]

Syntax Diagram

COMMIT WORK

Variants:

1. COMMIT WORK [AND WAIT].

2. COMMIT CONNECTION con.

Effect

Terminates an SAP LUW and stores the changes.

Variant 1

COMMIT WORK [AND WAIT].

Effect

The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the current SAP LUW in the process. In this case, COMMIT WORK performs the following actions:

It executes all subroutines registered using PERFORM ON COMMIT.

The sequence is based on the order of registration or according to the priority specified using the LEVEL addition. Execution of the following statements is not permitted in a subroutine of this type:

PERFORM ... ON COMMIT|ROLLBACK

COMMIT WORK

ROLLBACK WORK

The statement CALL FUNCTION ... IN UPDATE TASK can be executed.

Triggering an internal event for the Persistence Service of the Object Services.

If event handlers are registered by the Persistence Service, these collect the changes to the objects managed by the Persistence Service and transfer them via CALL FUNCTION ... IN UPDATE TASK to a specific update function module that is registered as the last update module.

This executes all high-priority (VB1) update function modules in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).

When all high-priority update function modules are completed successfully, the statement executes the low-priority (VB2) update function modules in the order of registration together in a common database LUW.

In parallel with the execution of high-priority update function modules, the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION are executed in a separate database LUW for each destination.

Within an update function module started using COMMIT WORK, the execution of statements that lead to a database commit is not permitted. In particular, the following are forbidden:

COMMIT WORK

ROLLBACK WORK

SUBMIT

CALL TRANSACTION

LEAVE TO TRANSACTION

CALL DIALOG

CALL SCREEN

The statement PERFORM ... ON COMMIT can be executed. The registered subroutine must be defined in the current function group.

It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.

It triggers a database commit that also terminates the current database LUW and closes all database cursors.

Triggers the TRANSACTION_FINISHED events of the system class CL_SYSTEM_TRANSACTION_STATE. The parameter KIND is set to the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.

If the statement COMMIT WORK is executed by calling special programs, be aware of the following:

In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.

In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until the COMMIT WORK statement is executed in the calling program.

Execution of the COMMIT WORK statement is not permitted during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.

System fields

sy-subrc Meaning

0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.

4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.

The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.

The COMMIT WORK statement closes all database cursors. Open SQL statements that access a database cursor later (SELECT loop and FETCH) lead to an untreatable exception.

COMMIT WORK also triggers a database exception in programs that are called using CALL DIALOG.

Variant 2

COMMIT CONNECTION con.

Note

This statement is for internal use only.

It cannot be used in application programs.

Effect

The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.

On the specified secondary database connection, the database commit:

Closes all open database cursors (OPEN CURSOR)

Releases all database locks

Note:

The COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.

Exceptions

Non-Catchable Exceptions

Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.

Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT

Cause: COMMIT WORK is not allowed in the update.

Runtime Error: COMMIT_IN_POSTING

[Former Member]

Hi Pranali

You can try creating dependant jobs.. or even try adding all these variants as different steps to the same job.

There might be some sort of lock/enqueue/dequeue check in your program...

Regards

Arun

[Former Member]

Hello all,

Thank u for ur replies...

the issue was, there was another job sometimes running simultaneously ,which was accessing the same interface...

thank u