ENQUEUE WORK PROCESS

It is used to lock and unlock the Objects during an update.These locks are displayed in SM12 and Held for longer hours until the transaction is committed or rollback.These locks are issued from a lock table which resides in the main memory of the instance where enqueue process is created/located. Enque Processes are configured by parameter rdisp/wp_no_enq=1. Generally One Enque Process for instance is sufficient,more then one is required in a massive update system. The Lock table size on the memory ranges between 4mb to 100 MB(200 MB in the Net weaver 7.3 Systems ) It is defined by parameter enque/table_size=4 to 200 MB. For 4mb of enqueue table size, the Number of lock/owners/objects/arguments can be restricted up to 3715.
Enqueue Flow:

• User submits the Request for an Update.
• The Dialog or Background Process Handles the Request
• Dia or BTC Processes communicates with Enqueue Process and obtains a lock on the record so that no other user has to write access to that record.
• The Lock will be held until the transaction is committed or rolled back The Locks are displayed in SM12.
• The Record is Committed to the database using a Transaction ID.
• The Locks are released.

Generally, the Enqueue time will be 1ms to 5 ms. if it is more then check whether update mechanism is active.
Locks for Application Servers:
The dialog or BTC process communicates with Message server through dispatcher to obtain a lock on the record during an update.
DIA–DISP–MSG—ENQ–ENQ TABLE—>ENQ–>MSG—>DISP—->DIA
BTC–DISP–MSG—ENQ–ENQ TABLE—>ENQ–>MSG—>DISP—->BTC
Due to the above process, the Enqueue time can go up to 100 ms.
From Net weaver 7.3 on-wards Enqueue and Message Server are installed together in separate Instance Named as ABAP SAP Central Services Instance. Every process can establish a direct TCP/IP Communication with Enqueue Process.
DIA—-ENQ–ENQ TABLE—>ENQ–>—>DIA
BTC—-ENQ–ENQ TABLE—>ENQ–>—>BTC
Enqueue Lock table Overflow:
When the Lock table is Full of Lock Owners or Lock Entries or Lock Arguments then the Over Flow Occurs.in this case the Size of Lock table can be increased up to enque/table_size to 100/200 MB.As part of the Monitoring, the Locks Held by dialog Process should not be more than one hour and the locks held by background can be hours and even days.Monitor the Locks and Update the Checklist and if it is long pending by a User
Check the Following.

• Check whether the User is Logged on SM04(Activity)
• Check Whether User is Disconnected due to Network issues(Sm21) but still active in SM04.
• When the Locks are held for a Long time and if any other User tries to access the same lock object then lock collision(rejections) occurs.
• Do not Delete the Locks from SM12 and it has to be done only as a last measure.
  Instead, the User can be logged off from SM04.
• Lock, User deletion is logged in SM21 and may be questioned during an Audit.

Lock Deletion Process:

• User Complains that he could not obtain a lock on the specific record.
• The record is Locked by some by other User which is displayed in SM12
• Check whether User is active if active advice the user to come out of the transnational screen to release the lock
• If the User is inactive, get the approval from the Lock Owner in Black and White(say email) to release the Lock
• Release the User from SM04 and lock should be released from SM12 else delete the lock in SM12.

Enqueue Dead Locks:
Due to Modularity between the modules, it is possible to lock the same LUW from Different Modules.
User-A User-B
Transaction-1 Transaction -2
a+b=x c+d=e
m+n=o t+r=a
c+d=e b+e=l
z+x=c a+b=x
Transaction-1 can be completed only when it obtains lock on a+b=x and similarly Transaction-2 can be completed only when it obtains lock on c+d=e.This is referred as a dead lock.
Report Dead Locks to SAP which might be unnoticed, SAP releases a patch/support package/note to resolve the deadlocks issue.
What happens to the locks and transactions that are committed during a system crash??
When ever a transaction is committed the locks are written to enque/backup_file=/usr/sap/SID/DVEBMGS00/log/ENQBCK . The Locks are reloaded into Enqueue Table during Enque/Instance restart. These Locks are inherited from Dialog Process and need to pass them to update for synchronous Update. rdisp/vbstart=1 parameter trigger the pending updates during a restart of the system.