Storage of Lock Tables
Selection tables have to be stored and managed centrally for all users and application servers. The SAP standard lock server cannot manage locks that are based on selection tables. For this reason, you 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.
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 of this one, 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; you find the locked selections themselves in transaction RSPLSE (see Display of 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.
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 enqueue server is set by default.) Therefore it is not necessary to copy the selections from the lock table to the user context. If you are locked onto a different server, the collision check is performed there with an RFC call.
Here too it may be useful to install the enqueue process not on the central instance but on a different (quicker) server. 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. For this reason this option is normally set by default.

In SAP lock management (transaction SM12), you find one lock record for each locked selection if you use table name RSPLS_S_LOCK_SYNC; you find the locked selections themselves in transaction RSPLSE (see Display of Active Locks).

This option provides a better performance than storing the lock table in the standard SAP lock server. However, you must ensure that the server with the lock table is available if transaction data is to be stored with selections. You can set the size of the shared object memory with profile parameter abap/shared_objects_size_MB.
Selection tables are stored in SAP liveCache.
This option is only available if SAP liveCache is installed. In this case, the collision check is also performed in SAP liveCache.

This option is intended for large installations where you need to lock a large number of complex selections. For more information about configuring the liveCache as a lock server, see SAP Note 816730.