Storing the Lock Table
The selection tables have to be stored and managed centrally for all users and application servers. The SAP Standard Lock Server cannot manages locks that are based on selection tables. You therefore have to make your own settings for storing locks that are described by selection tables.
The current locks are stored in a lock table. On the Lock Table tab page, you specify where you want to store the lock table. There are three options for storing the lock table. You can select a suitable server depending on the storage type.
Storing the Lock Table on the SAP Standard Lock Server
The selection tables are compressed and stored on the SAP standard lock server.
The collision check for locks is not performed by the lock server, but by an ABAP program. This check requires that the selection tables are copied to the user context. The collision check is set by default on the server you are logged on to. If you select a different, fixed server instead, the collision check is performed there with an RFC call.
This can be advantageous if the enqueue process is installed on a different (fast) server, and not on the central instance in order to possibly speed up the copy process for selections from a lock table to the user context. The server with the enqueue process is marked as such in the server selection.
In SAP lock management (transaction SM12), you use table RSPLS_S_LOCK to display the compressed lock records. To find the actual locked selections, you need to call transaction RSPLSE (see Displaying Active Locks).
This option requires the least administrative effort. It is suitable for small and mid-size installations. You can set the size of the lock table using the profile parameter enque/table_size.
Storing Lock Tables in the Shared Object Memory of an Application Server (Default System Setting)
The selection tables are not compressed. They are stored in a shared object memory area. This is the default value of the system unless you are using the SAP Standalone Engine Server, in which case the above option (store the lock table in the SAP standard lock server) is preset.
This area is bound to an application server. In this case, the SAP standard lock server only contains a pointer to the selection (one lock record for each selection table). You need to specify a server that contains the lock table in Shared Object Memory. The collision check is performed on this server. (The standard setting is for the enqueue server to be set.) It is therefore not necessary to copy the selections from the lock table to the user context. If you select a different server instead, the collision check is performed there with an RFC call.
Here too it may be useful to install the enqueue process on a separate (faster) server rather than on the central instance. This is because during a lock process, the selections in the shared object memory are synchronized with the pointers on the SAP standard lock server. This synchronization is performed fastest if the server with the enqueue process is the same as the server with the lock table. This option is therefore normally the default setting.
In SAP lock management (transaction SM12), you find one lock record for each locked selection if using table name RSPLS_S_LOCK_SYNC. You can find the actual locked selections in transaction RSPLSE (see Displaying Active Locks).
This option provides better performance than storing the lock table in the standard SAP lock server. The lock table has to guarantee the availability of the server though if you want to lock transaction data using selections. You can set the size of the shared object memory using profile parameter abap/shared_objects_size_MB.